On Sat, Jul 11, 2009 at 10:46:07AM +0100, David Chisnall wrote: > 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).
Okay, so I'm back to the drawing board for this. But it should be relatively save to use this as a temporary workaround, shouldn't it? > 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. If I understand correctly, that would mean decoupling CORefs from object pointers in ETSerializer. I think this could be done by turning the unstoredObjects/storedObjects hash tables into map tables that store pointer/CORef-pairs without disturbing any other code in EtoileSerialize. Although I'm not quite sure what to use as a source of CORef identifiers. Perhaps the serializer could just have an instance variable that is incremented (and possibly reset for each new version)? > 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. Yeah, right. I read that the deserializer is still lacking some code to compare the size of the integer deserialized with the local class. Some kind of overflow handling will definitely be in order at that place. Cheers, Niels _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
