> 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
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
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.)