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