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. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
