On Fri, Sep 07, 2007 at 02:50:21PM +0300, Giorgos Keramidas wrote: > On 2007-09-07 00:09, Luigi Rizzo <rizzo_at_icir.org> wrote: > >On Fri, Sep 07, 2007 at 01:26:47AM +0300, Giorgos Keramidas wrote: > >>On 2007-09-06 11:10, Luigi Rizzo <rizzo_at_icir.org> wrote: > >>> hi, > >>> i was wondering what is the proper way to tell a 64 vs 32 bit > >>> architecture. > >>> > >>> I see that some code in sys/ uses ' #ifdef __LP64__ ' but i am not > >>> sure if this is generic enough (ie not gcc or FreeBSD specific), > >>> and also suitable for userland (i.e. works on linux or other platforms > >>> as well). > >> > >> This is usually needed to differentiate between a feature "X" which > >> behaves differently in amd64 vs. i386 vs. sparc vs. sparc64, etc. > > > > i am actually looking at pointer sizes, as i need to do some pointer > > manipulation going through intptr_t, and need to know that in the > > preprocessor because some constants need to be 32 or 64 bit depending > > on that, and are not trivial (i.e. not 0, 1 or something i can build > > with size-agnostic expressions) > > An intptr_t can safely hold any void pointer value, and C99 says: > > % 7.18.1.4 Integer types capable of holding object pointers > % > % 1 The following type designates a signed integer type with the > % property that any valid pointer to void can be converted to > % this type, then converted back to pointer to void, and the > % result will compare equal to the original pointer: > % > % intptr_t > > What sort of manipulation? Can this sort of manipulation be written in > a way that uses sizeof(intptr_t) instead of 4, 8, or preprocessor magic? i need to do this: #ifdef BUILT_FOR_64BIT_POINTERS #define MY_MAGIC 0xdeadbeefd00de123 /* 64 bit */ #else #define MY_MAGIC 0xdeadbeef /* 32 bit */ If you know of a way to implement this without preprocessor magic, i am all ears. If the values were simpler (eg all ones or so) i could have used ~((unitptr_t)0) but this is not the case here cheers luigiReceived on Fri Sep 07 2007 - 10:05:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:17 UTC