gnustep-dev
[Top][All Lists]
Advanced

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

@encode on LP64x


From: David Ayers
Subject: @encode on LP64x
Date: Sun, 17 Jul 2005 23:21:47 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1

Hello,

A while back Zem started a short thread which touched on this subject:

http://lists.gnu.org/archive/html/discuss-gnustep/2004-01/msg00638.html

and that already made me shiver.  Now that the GNU runtime is being used
on 64 bit architectures we are starting to see the effects we only dared
imagine before...

(the following results are from the GNU runtime, but I don't believe
these differ in principle from the apple runtime with possibly the
exception of long double which seems buggy here.)

i686-pc-gnu-linux:
@encode(char)                c:1
@encode(unsigned char)       C:1
@encode(short)               s:2
@encode(unsigned short)      S:2
@encode(int)                 i:4
@encode(unsigned int)        I:4
@encode(long)                l:4
@encode(unsigned long)       L:4
@encode(long long):          q:8
@encode(unsigned long long): Q:8
@encode(float)               f:4
@encode(double)              d:8
@encode(long double)         :12
@encode(int8_t)              c:1
@encode(uint8_t)             C:1
@encode(int16_t)             s:2
@encode(uint16_t)            S:2
@encode(int32_t)             i:4
@encode(uint32_t)            I:4
@encode(int64_t)             q:8
@encode(uint64_t)            Q:8

amd64-unknown-freebsd7.0:
@encode(char)                c:1
@encode(unsigned char)       C:1
@encode(short)               s:2
@encode(unsigned short)      S:2
@encode(int)                 i:4
@encode(unsigned int)        I:4
@encode(long)                q:8
@encode(unsigned long)       Q:8
@encode(long long):          q:8
@encode(unsigned long long): Q:8
@encode(float)               f:4
@encode(double)              d:8
@encode(long double)         d:16
@encode(int8_t)              c:1
@encode(uint8_t)             C:1
@encode(int16_t)             s:2
@encode(uint16_t)            S:2
@encode(int32_t)             i:4
@encode(uint32_t)            I:4
@encode(int64_t)             q:8
@encode(uint64_t)            Q:8

Every NSCoding archive (gorm/nib-files) currently which included
@encode(long) on 32-bit archs cannot be decoded correctly on LP64I32.

Of course the implications go beyond archives and DO as the most popular
API's (OPENSTEP/Cocoa in particular) have different value ranges
available for the same methods and instance variables on different
architectures.

So my question is, is the general consensus that encoding must be done
with the size specified int types and how should long doubles be handled
in a portable fashion?

Of course using the size specified types, the coding implementations
would still have to abide by the lowest common denominator (i.e. ILP32)
when archiving values even if the ivars use the standard types which
theoretically could hold values outside the range...  in which case I
would recommend raising exceptions if not some default were set to allow
archiving in native types.  Note that the principal problem wrt the
valid ranges is also not worked around by alternative archive formats
like XML-based formats.

Cheers,
David

PS: The reason I refrain from cross posting via CC is because the
GNUstep lists are moderated for non-subscribers.  Please keep that in
mind when replying.  I've cross-posted via BCC as a heads-up for the
GNUstep folks who may not be subscribed here.




reply via email to

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