"Jacques A. Vidrine" wrote: > On Tue, Apr 29, 2003 at 12:13:15PM -0700, Terry Lambert wrote: > > It probably would have been better to just put a per record byte > > order maker in there, instead of using a version number, but you > > would still have the same problem for the records without the > > marker, so you'd have to ignore them as "suspect". > > There _is_ a per-record marker. See my posting to -arch yesterday if > interested. It's a version marker, not something like 0xffeefeef, which would let you adaptively use the file byte order, or convert it to host byte order, automagically, as the file is referenced. I understand why you did it the way you did; I'm not complaining (except for history not supporting a byte order marker, and no way to reverse engineer one into there). You probably need both a version marker for the file, and a byte order marker per record; it works as it does not because you didn't change the record size between versions (kind of makes you worry about that happening, now...). A byte order marker per record would "just work", albeit more slowly, on a different architecture. I hope someone is thinking about this INRE moving UFS/UFS2's between SPARC and x86; I know that the last consensus was to punt on binary FS compatability, and not support it, but it should be possible to support it, even if it's not likely to be written in the near future. -- TerryReceived on Tue Apr 29 2003 - 13:02:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:05 UTC