On 11 Jul 2009, at 13:53, Niels Grewe wrote: > 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?
You can make it an intptr_t as a temporary work-around, as long as you make sure that everything is updated to work correctly with that. I don't really like doing this though because it means we're using a lot more space on 64-bit systems. If you have more than 2^32 objects being serialised in a single invocation then you are probably doing something quite badly wrong. >> 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)? The COREF_FROM_ID() macros should be being used everywhere to turn pointers into CORefs. If it isn't being used somewhere, that's a bug. For 32-bit, it's a simple cast, for 64-bit it should be calling a function that looks up the object in the map. >> 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. Yup. It's a problem, unfortunately, that isn't trivial to solve. Truncation is actually quite easy (we can just do it silently and as long as we are endian-aware it's fine - if your value overflows then you probably had a bug to start with), the problem is going the other way where we need to make sure we either sign- or zero-extend the value by the correct amount depending on the size and signedness of the destination. David _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
