[Top][All Lists]

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

Re: [Lightning] WORDSIZE detection with GCC 4.2

From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] WORDSIZE detection with GCC 4.2
Date: Mon, 2 Sep 2013 15:09:14 -0300

2013/9/2 Vitaly Magerya <address@hidden>:
> On 09/02/2013 18:47, Paulo César Pereira de Andrade wrote:
>>   I just started working on having 2 vms (i386 and amd64) of FreeBSD 9.1
>> so that I can keep a test environment.
> Cool, thanks.
>>> Is there a better solution?
>>   There may be something else in "cpp -dM /dev/null", or some header
>> like <limits.h>.
> Yea, I looked at those, and didn't find anything appropriate; you can
> have at look yourself at [1] (note that WORD_BIT is size of 'int', so
> it's 32 on both i386 and amd64).
> Comparing SIZE_T_MAX from limits.h with 0xffffffffU maybe? There's also
> UINTPTR_MAX in stdint.h, which looks more appropriate (if relying on
> presence of stdint.h is something you're willing to accept).

  It already includes stdint.h since 2012-12-02 and that did work on
all tested platforms so far.

> What you ultimately want is a way to tell between ILP32, LP64 and fail
> on everything else. Just testing for SIZE_T_MAX doesn't really guarantee
> that you've got one of those two. Testing for a combination of

  I am afraid of touching those defines in lightning.h because I no longer
have access to some hosts, e.g. gcc build farm linux ia64 and hpux are
dead, I am still waiting for some hosts in to be revived...
  What FreeBSD version are you using? FreeBSD 9.1 has this in

/* GNU and Darwin define this and people seem to think it's portable */
#if defined(UINTPTR_MAX) && defined(UINT64_MAX) && (UINTPTR_MAX == UINT64_MAX)
#define __WORDSIZE              64
#define __WORDSIZE              32

>>   It should work with CFLAGS="$CFLAGS -D__WORDSIZE=32" as
>> it would not be overwritten anywhere...
> Right, but then you'd need to document this so that every application
> that uses lightning compiled with the same -D, and that is highly
> inconvenient for the applications.
> [1]


reply via email to

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