[ZooLib-dev] Support for 64 bit offsets in ZStream

[Andrew G. <ag...@em...>]

I'm about to check in support for 64 bit offsets in ZStream. Most 
ZStream derivatives hang off ZStreamR or ZStreamW and so are mostly 
unaffected by this change, except where they implement copy from/to.

The affected entry points are:
ZStreamR:
void CopyAllTo(const ZStreamW& iStreamW, uint64* oCountRead, uint64* 
oCountWritten) const;
void CopyTo(const ZStreamW& iStreamW, uint64 iCount) const;
void CopyTo(const ZStreamW& iStreamW, uint64 iCount, uint64* 
oCountRead, uint64* oCountWritten) const;

void Skip(uint64 iCount) const;
void Skip(uint64 iCount, uint64* oCountSkipped) const;
void SkipAll(uint64* oCountSkipped) const;

ZStreamW:
void CopyAllFrom(const ZStreamR& iStreamR, uint64* oCountRead, uint64* 
oCountWritten) const;
void CopyFrom(const ZStreamR& iStreamR, uint64 iCount) const;
void CopyFrom(const ZStreamR& iStreamR, uint64 iCount, uint64* 
oCountRead, uint64* oCountWritten) const;

ZStreamXXPos:
uint64 GetPosition() const;
void SetPosition(uint64 iPosition) const;
uint64 GetSize() const;
void SetSize(uint64 iSize) const;

And of course the actual Imp_XXX methods. Read and write methods still 
take and return size_t parameters, as you can't read or write more data 
in one hit than your address space can accomodate.

I've also tightened up the behavior of SetSize and SetPosition. A 
SetSize operation that detectably fails will throw a 
ZStreamWPos::ExBadSize exception. A SetPosition that detectably fails 
will throw a ZStreamRPos::ExBadPosition. Both inherit from 
std::range_error. This did highlight a weakness in how SetPosition is 
defined to behave. If SetPosition is called on a ZStreamRPos outside of 
the range of bytes available then the behavior was supposed to be 
undefined -- that is, it was not defined what the actual position would 
be after the call. It now throws an exception. If SetPosition is called 
on a ZStreamWPos or ZStreamRWPos outside of the range of bytes 
available then it's supposed to extend the range of bytes available, 
with the new bytes having undefined values, and if the size extension 
fails then a ZStreamWPos::ExBadSize is thrown. So code that's passed a 
ZStreamRWPos expecting only a ZStreamRPos has would always have behaved 
differently if it ever strayed outside the defined range depending on 
what actual stream was passed to it. The fix would be to have a 
separate entry point for ZStreamWPos/ZStreamRWPos that sets the 
position and extends the size if necessary. I'm not sure if that's 
warranted right now.

A+
-- 
Andrew Green                           mailto:ag...@em...
Electric Magic Co.               vox: +1 (831) 621 1822