from fpc/packages/fcl-base/src/inc/zstream.pp

I'm not really sure why this is in the destructor for tdecompressionstream.

  if FZRec.avail_in  0 then
    Source.Seek(-FZRec.avail_in, soFromCurrent);

my tdecompressionstream is fed by a tideadecryptstream - when tdecompressionstream is freed it causes that seek in the decrypt for some reason? , which isn't supported by the tdecryptionstream and it throws a EIDEAError - or is there a problem with the source stream?

generally I feel that exceptions are somehow uncivilized, so avoiding one so totally unnecessary (in context, at least) would be appreciated.

Dave

To reposition the source stream on the last actually read data.

my tdecompressionstream is fed by a tideadecryptstream - when tdecompressionstream is freed it causes that seek in the decrypt for some reason? , which isn't supported by the tdecryptionstream and it throws a EIDEAError - or is there a problem with the source stream?

No, this is "normal".

generally I feel that exceptions are somehow uncivilized, so avoiding one so totally unnecessary (in context, at least) would be appreciated.

I'll introduce a property in TDecompressionstream: 'SourceSeekable' or so which can be used to control the behaviour.

Another solution is to implement a long-standing idea of mine:

to introduce a property in TStream:
  StreamCapabilities : TStreamCapabilities;
with
  TStreamCapability = (scSeekForward,scSeekBackward,scRead,scWrite,scSize);
  TStreamCapabilities = set of TStreamCapability;

I think I'll go for the latter one.

Michael.

I like the capabilities solution. It has the feel of "the pascal way to do it." There shouldn't be anything in the stream when free is called, will research more what all is going on with that.