>
>
> > There is something wrong around lib/strftime.c:946
> >           if (negative_number)
> >             u_number_value = - u_number_value;
> >
> > u_number_value being unsigned, this is wrong.
>
> I don't see anything wrong there.  The value of
> -X is well-defined if X is unsigned int; it's
> equivalent to ~X + 1.  Can you supply a test case
> illustrating the actual bug?
>
>
When my compiler issues a warning like :

unsigned.c
unsigned.c(3) : warning C4146: unary minus operator applied to unsigned
type, result still unsigned

I tend to care about it. If it is on purpose, then I'm ok with it albeit I
would have prefered something less error prone
(I mean human interpretation error :-) )


>  > In src/dispnew.c:6402, height and width should probably be unsigned. The
> > checking by
> > INT_ADD_RANGE_OVERFLOW results in a compiler warning about integral
> > constant overflow
> > because it tries to compute (INTMIN - 2) which obviously is out of range.
> > The value is not used in this case, but the compiler may emit the warning
> > anyway.
>
> We don't need to modify the mainline Emacs code in order to
> pacify third-party compilers that issue incorrect warnings.
> We can safely ignore these warnings and leave the code alone.
>

My past experience with stuff like pdftex (many years !)
is that compiling with a completely different
compiler may reveal useful to find errors in already tested source code.
The cleaner, the safer.

I don't know to which extent the FSF wants to support compilation of emacs
x64 (but that applies to x86 too) with the MS tools (even if they are
freely available).
I did it because I'm using it this way, but that should be doable with
MINGW x64 (or so I guess).
With the MS tools, emacs does not compile out of the box. There are errors.
There are also lots of warnings and when something does not work, I try to
remove warnings first.
All in all,  at least for the record, it may help people who would need an
emacs/x64/windows this way.

Best regards,

Fabrice