[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts
From: |
Paul Eggert |
Subject: |
Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts |
Date: |
Fri, 29 Apr 2011 02:06:15 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 |
On 04/29/11 01:49, Eli Zaretskii wrote:
> Maybe it's just me, but I'm slightly worried by these names: they
> sound as if they represent pointers,
Yes, that's exactly what they're for. EMACS_INTPTR is the Emacs
analog of the standard C type intptr_t, which is a integer type that
is wide enough to hold a pointer, i.e., one can convert from void * to
intptr_t and back again without losing information.
The name "intptr" may be a bit confusing to a reader who doesn't
know C99, but once you're used to the standard meaning, any other name
would sound weird.
> you use them as integer types to avoid compiler warnings and casts
> (even though you used pointer types such as intptr_t to define these macros).
No, intptr_t is an integer type; it's not a pointer type.
> How about EMACS_LONG and EMACS_ULONG instead?
That wouldn't be good, because in a typical 32+64-bit host, EMACS_LONG
would be narrower than EMACS_INT.
>> > - if (data != NULL && data == (void*) XHASH (QCdbus_session_bus))
>> > + if (data != NULL && data == (void *) XPNTR (QCdbus_session_bus))
> I wonder if we aren't obfuscating the code a bit too much, since XHASH
> says something about its argument, while XPNTR is too general to
> convey any such useful information. Unless, that is, you are saying
> that the use of XHASH here was bogus to begin with, and all that was
> needed was a pointer.
Yes, that's what it's saying. void * is supposed to hold only a
pointer: in general it can't hold a pointer plus a tag. So the
old code wasn't correct. (It was good enough for the current ports,
but not good enough for a 32+64-bit port.)
>> > Step 2 will change EMACS_INT to be 64 bits on 32+64-bit ports.
>> > That is a bigger deal, and I'll send a later email about it.
> When you do that, please don't hardwire "long long" for the 32+64-bit
> builds. That type is not standard enough in C90; in particular the
> MSVC compiler we still support for Windows doesn't have it, but it
> does have compatible __int64 and __uint64 types.
Thanks, I hadn't thought of that. Before I got your email I already
sent out a simple patch
<http://lists.gnu.org/archive/html/emacs-devel/2011-04/msg00908.html>
that did not use __int64 (so it continued to use 32-bit int on
Windows). I will look into extending that patch, so that it also works with
__int64.
- bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, Paul Eggert, 2011/04/29
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, Eli Zaretskii, 2011/04/29
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts,
Paul Eggert <=
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, Eli Zaretskii, 2011/04/29
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, Stefan Monnier, 2011/04/29
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, Eli Zaretskii, 2011/04/29
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, Lars Magne Ingebrigtsen, 2011/04/29
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, Paul Eggert, 2011/04/29
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, David De La Harpe Golden, 2011/04/29
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, Stephen J. Turnbull, 2011/04/30
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, Paul Eggert, 2011/04/29
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, Paul Eggert, 2011/04/30
- Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts, Eli Zaretskii, 2011/04/30