emacs-devel
[Top][All Lists]
Advanced

[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: Mon, 20 Feb 2012 12:43:34 -0800
User-agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 02/20/2012 11:20 AM, Fabrice Popineau wrote:
> Windows and Linux does not follow the same 64 bits rules (LLP64 vs LP64).

Yes, and that was why I suggested the heuristic that I suggested.

The Emacs code is currently quite portable to standard GNU hosts,
which are LP64 or ILP32 or ILP32LL64.  If code portable to these
hosts uses 'int', there should be no need to change the 'int' to
'intptr_t', because such a change would already be needed for the
LP64 port.  Most of your patch's changes to the mainline sources
were of this nature, and should therefore be omitted.  The only
changes actually needed for porting to an IL32LLP64 host should be
the relatively small number of changes that I mentioned in my
previous message.

>     -      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
>     +      int i = 0;
>     +      intptr_t aligned = (intptr_t) ABLOCKS_BUSY (abase);
>      
>     Here, the value of 'aligned' is either 0 or 1, so there's
>     no need to change its type.
> 
> It is kind of strange to cast to intptr_t to store the result
> in a variable of different type ?

The cast to intptr_t (instead of to int) is to avoid GCC warnings
about casting a pointer to an integer of a different size.  Using
intptr_t is helpful, because these warnings are typically useful
and in the rare cases where they're not (such as here) it's
helpful to insert a cast so that GCC does not cry wolf.

In contrast, there is no need to declare 'aligned' to be wider
than 'int'.  Generally the Emacs source code uses 'int' for random
integers that are guaranteed to fit in int range, which is the
case here, so we should leave the 'int' alone.

This is just one example, but I hope you get the general idea:
please minimize the changes made to the mainline source code.
Ideally any changes for Windows 64 would be only to the
Windows-specific part of the code, so that we don't need to worry
about its effect on GNU hosts.  In practice we can't always
achieve this ideal, but nevertheless it's important to minimize
the changes to mainline code, as this saves everybody's time.




reply via email to

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