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