[ZooLib-dev] More thoughts on stream positions and sizes

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

I've had a few more days to think about the SetPosition issue that I 
recognized in revamping the ZStreamXPos API to use 64 bit offsets. And 
I've realized that (again) UNIX had it right all along. To recap, code 
that takes a ZStreamRPos and tries to position it beyond its physical 
end will see different behavior when it's actually passed a 
ZStreamRWPos than if it's passed a ZStreamRPos. To whit, the former 
will quietly resize the stream if physically possible, whereas the 
latter will now throw an exception (previously its behavior was 
undefined).

The UNIX (and Win32) approach is to allow SetPosition to take any 
value, and to report that value when GetPosition is called. If 
ZStreamRPos::Read is called when the position is at or beyond the end 
of stream then it just reads zero bytes and leaves the position 
unchanged, and higher level code can make of that what it will. If 
ZStreamRWPos::Write is called then the underlying stream is extended 
appropriately, with any gap between the end of stream and the current 
position being filled with undefined data.

I've gone through all of ZooLib, and other code, and updated it to 
reflect these semantics. It's an almost completely safe change in that 
it just _removes_ a constraint on what can be passed to SetPosition. 
The only difference in behavior code would see is if it called 
SetPosition and then GetSize and required that the size be at least as 
big as the position. That's not a pattern that shows up anywhere in 
ZooLib, but let me know if this is something you need to do or indeed 
can think of a scenario in which it makes sense.

Code that calls SetPosition without first calling SetSize will 
generally be doing so in order to write something, in which case the 
stream will be extended as necessary when the write occurs. If it's 
calling SetPosition to read something, and that position is at or 
beyond the end of stream, then in either case, under the old scheme or 
the new scheme, it's going to see zero bytes -- the old scheme only 
extended the size to *match* the position, and there were still zero 
bytes beyond the position.

The only ZooLib code I haven't updated to reflect these semantics is in 
ZBlockStore_SlotStore. The ZBlockStore_SlotStore::Stream updates the 
secondary slot referenced by a position as it reads, writes and when 
SetPosition is called. Maintaining a logical and physical position 
would be straightforward, but I don't want to futz with that code for 
now -- it's working fine for current purposes, and new code should 
probably use ZBlockStore_PhaseTree.

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