On Mon, Oct 01, 2012 at 05:07:48PM +0200, Henrik Sperre Johansen wrote: > On 01.10.2012 15:44, Igor Stasenko wrote: > >On 1 October 2012 14:43, Sven Van Caekenberghe <[email protected]> wrote: > >>On 01 Oct 2012, at 14:01, Henrik Sperre Johansen > >><[email protected]> wrote: > >> > >>>Endianness in header depends on the platform the image was saved on. > >>>Which for all practical purposes, means little-endian these days. > >>How can an image be cross-platform, but the header not ? > >> > >Just another artifact of incremental development, i guess. > >I don't know what reasoning was behind this, but IMO, defining header > >to have fixed byte order > >would be much better. Of course, it is always easier to think backwards. > >However, things like IP header, were existed before squeak image > >format. So, again, > >i am clueless why guys decided that doing like it's done is a Good Idea > >(tm). > > > IIRC, the code that writes the image header is in Slang. > Using uints for fields there would be a logical choice, I would guess.
Yes, it is done in #checkImageVersionFrom:startingAt: > > TBH, I don't think it would be much better if a byte order were enforced > for a single header field only. > > Though, I personally would think it'd be nice if the format field were > to be expanded and kept symmetrical. > That way, deciphering the image formats numerical value could be done > independently of endianness (and knowing what #'s are valid formats). > > As nice as backwards compatability though, considering there would be no > breaking image format changes per se? Probably not. It would be straightforward to design a new object file header, so long as the VM retains the ability to read the old one. The resulting image could not be read by older VMs but otherwise there would be no problem. Dave
