John wrote:
>> only one warning: mdb.c(7224): warning C4333: '>>' : right shift by too large amount, data loss.
 
It looks to me that the SETDSZ(node,size) macro that is generating that warning on that line
is called three times in mdb.c, twice with a size_t (unsigned int) size, and once, on line 7224
(line varies by version of mdb.c) with an indx_t (unsigned short) size.
 
The SETDSZ() macro does a right shift by 16 bits to get the higher two bytes of the size,
which is necessary when the size is a size_t (the other two calls), but always produces
zero when the size is an unsigned short (this call giving the warning.)
 
The poorly worded compiler warning is telling us that it's silly (from the perspective of
the compiler) to be right shifting a 16 bit unsigned short by 16 or more bits to the right.
The result will -always- be zero, suggesting to the compiler that the shift might not be
what the programmer intended. 
 
If this were my software, I would consider changing that invocation of the SETDSZ() macro
 
from:
    SETDSZ(node, nsize);
 
to:
    SETDSZ(node, (size_t)nsize);
 
to avoid the warning, with no impact on the resulting machine code, but with the benefit
of (minimally) documenting, right in the source code, awareness that this invocation of the
SETDSZ is working with a size that is not of the size_t type expected by the SETDSZ macro.
 
I have -not- tested the above claims in a Microsoft development environment ... the possibility
for error is non-trivial.
 
It's better in my view to have no warnings, if that can be done without compromising the
generated code, and only a minor inconvenience to the source code.
 
Even for experienced C coders (such as myself, who has written many hundreds of thousands
of lines of C code in the last 40 years), the difference in time spent to ensure that all is well,
so far as compiler warnings can detect, is substantially less ... 0 minutes versus N minutes,
when there are zero warnings, rather than one or more warnings.
 
In my experience, allowing -any- warnings increases the risk that another future warning
that was important will be ignored (probably not by Howard, who knows exactly what is
going on, but perhaps by someone else working with the code.)
 
-- 
                Paul Jackson
                pj@usa.net