Hi Niels, I've taken a look at the diff, but there are a lot of problems with it. You are not seeing them because the PTR_VAL() macro is hiding the warnings, but making CORef 64-bit is going to break everything where we are storing CORefs in NSMapTables (i.e. almost everywhere).
The correct 64-bit fix for this is to implement the COREF_FROM_ID() macro such that it looks up objects in a map table. If the object doesn't exist, give it a new number and add it to the hash table. Note that even if we make CORef the same size on both platforms, we can't exchange serialised graphs between 32-bit and 64-bit platforms without some extra work because int will be a different size. David On 11 Jul 2009, at 07:19, Niels Grewe wrote: > Hello, > > playing around with EtoileSerialize a bit, I found some 64bit issues > in > the XML serializer. I've uploaded a diff to the review board that > fixes > them by turning the CORef type into a 64bit value. Please let me know > what you think. I'm only aware of one place in ETDeserializer.m (line > 105), where the value will still be truncated on 32bit. This could > cause > problems when trying to deserialize an object from a 64bit host on > 32bit. > Please also note that at the moment there is a bug in GNUstep's > NSMapTable implementation that causes occasional segfaults. (Already > reported as #27008) > > Cheers, > > > Niels > > _______________________________________________ > Etoile-dev mailing list > Etoile-dev@gna.org > https://mail.gna.org/listinfo/etoile-dev _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
