[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Windows 64 port

From: Paul Eggert
Subject: Re: Windows 64 port
Date: Tue, 28 Feb 2012 14:09:03 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1

On 02/28/2012 01:00 PM, Fabrice Popineau wrote:

> int aligned = (ABLOCKS_BUSY(abase) != NULL);
> would have been cleaner.

Perhaps, but it'd also be a bit slower, and at any rate
this should be a separate patch, since the change
is independent of the Windows 64 port.  Any Windows 64
patch should be limited to issues that are actually
needed for a Windows 64 port.

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

Please bear in mind that the code is already
tested to LP64 hosts.  Any bug related to this
particular code would also be a bug on LP64 hosts,
no?  So, it's not likely that any bug here is specific
to Windows 64.  If there is a bug, it should be
describable and fixable independently of Windows 64.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]