🚀 go-pugleaf

Bob,

Since wsprintf/printf/fprintf and company take a variable argument list, the
arguments are placed on the stack as 'promoted' types unless you explicitly
use a cast.  Therefore the values go in as 32 bit ones.  Unsigned short ints
(16 bits) are promoted to unsigned int so their numerical values are
unchanged.  Even were they to be promoted to signed int, none of the values
are candidates to even approach 32767, the largest short int, let alone
overflow to set the sign bit.

Again, thanks for your help.  I kept staring at it, looking for exotic
reasons for the problem, while you picked up on what the problem was
immediately.

.  Ed

> Bob Gonder wrote in message
> news:gmkccv04t9524h43nqd9dfifq58hvuvcc4@4ax.com...
>
> >> Should those be %2hd and %4hd (words, not 16bit ints)?
> >
> >It doesn't matter.  The d is 32 bits and since the numbers
> >are dates and times, none of them approaches setting the
> >sign bit.
>
> Yeah, but they are 16 bit values. In the old days, the compiler
> would have pushed the 16bit values and the library would have
> interpreted them as 32bit (combining two 16bit values).  I guess
> today, the 16bit values are pushed as 32bit, and the library
> knows that reguardless of the stated size, they are always
> 32bit  on the stack (unless they are 64 <g>).
> Also, one might envision this happening:
> mov cx,st.wMINUTE
> push ecx
> call printf
> What's in the upper 16bits?  With %hd I would expect the library
> to handle it correctly (ignore the upper 16).