[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 16:20:34 -0300 |
2013/9/2 Vitaly Magerya <address@hidden>:
> On 09/02/2013 21:09, Paulo César Pereira de Andrade wrote:
>>> 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.
>
> Hey, I completely missed that. May I ask why you don't use intXX_t for
> jit_intXX_t then?
It was just derived and/or cut&paste from older code I wrote, before
ever considering using stdint.h. It is working, so no need to rush to
change it :-)
>>> 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
>>> SIZE_T_MAX, INT_MAX, LONG_MAX, LLONG_MAX and UCHAR_MAX maybe?
>>
>> 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 snakebite.net to be revived...
>
> I see.
>
>> What FreeBSD version are you using? FreeBSD 9.1 has this in
>> stdint.h:
>>
>> /* 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
>> #else
>> #define __WORDSIZE 32
>> #endif
>
> The problem actually surfaced while testing on FreeBSD 8.4, where this
> define is missing. I guess it would make sense to add this condition to
> the end of 'ifndef __WORDSIZE' switch and be done with it.
It looks pretty sane. I will do it. I should make a new release soon
with this and a few other correction.
Thanks,
Paulo