[fpc-devel] zstream, fpc and lazarus

Michael Van Canneyt michael at freepascal.org
Sun Dec 2 12:10:06 CET 2007



On Sun, 2 Dec 2007, Daniël Mantione wrote:

> 
> 
> Op Sun, 2 Dec 2007, schreef Sergei Gorelkin:
> 
> > Daniël Mantione wrote:
> > > 
> > > Okay, that explains it. The memory stream is the only solution to seek in
> > > a sane way. Now we could switch to Delphi behaviour, but to be honest, I
> > > don't want to enforce the memory stream to everyone who wants to use a
> > > compressed stream; it should be usable on plain files.
> > > 
> > > I'm going to interpret the Delphi docs liberally; "the beginning" is the
> > > beginning of the zstream, not the beginning of the file. If you want to
> > > reset the source stream, you will have to reset the source stream :) Ok,
> > > it is a Delphi incompatibility, but really a corner case, and doing so
> > > has many advantages.
> > > 
> > I believe that fpreadpng.pp must be fixed, too. At least it should reset
> > memory stream to zero position itself and don't assume that zstream will do it
> > instead. At maximum everything can be done without memory stream at all - PNG
> > format is designed to be sequential.
> > 
> > As for zstream behaviour, I fully agree: it should remember source stream
> > position at creation time and seek to it at reset. This way, compatibility
> > existing with Delphi code won't be broken, because its authors supply streams
> > in which compression data starts from the beginning.
> 
> We actually don't need remember the start position, I simply to a 
> backwards seek, which does the trick.
> 
> > Furthermore (and I issued a corresponding patch for the previous version), at
> > destruction decompression stream should adjust source position to the end of
> > actually decompressed data. This way makes it possible to process streams that
> > have compressed data followed by some other data.
> 
> I agree, but I would like to be carefull about one thing: zstreams read 
> from pipes or sockets. If someone closes a socket zstream early, a seek to 
> end would result in an exception. Is there a way we can detect a stream to 
> be seekable?

Not currently. This is in the pipeline (sic). This is one of the things I wanted
to address when re-creating zstream. Originally I planned to do this myself, 
remember ? ;-)

The idea is to create

  TStreamCapability = (scRead,scWrite,scSeekForward,scSeekBackward,scSize);

  Class Function TStream.StreamCapabilities : TStreamCapabilities;

And to check this. It can be used to optimize certain operations. Now,
a non-seekable stream without size is assumed in FPC, making some operations
slow. Delphi assumes a stream which is seekable, with size, making some 
operations impossible, like pipes or sockets. I submitted a bugreport about
this way back in 2000.

Michael.


More information about the fpc-devel mailing list