Marco van de Voort wrote:

> Better have a separate way. Otherwise you can't set e.g. a compressionlevel
> for that stream, _or_ you have to have lots of different constructors.

Compressors can require any kind and number of arguments, that must be
reflected somewhere, e.g. in the specific constructor. It's not
guaranteed that a compressor will have usable defaults for all

For now only decompression will be supported by a general function,
where the decompressor (class) can be selected from the file extension
or header, and the decompressor then should be able to determine the
appropriate parameters from the concrete data source.

> One other thing to keep in mind (iirc) is that some algo's require the
> uncompressed size to unpack, and some the compressed size. So probably
> your interface has to support both.

Good to know. But the uncompressed size cannot be known in the general
case, so that such information must be supplied together with the
compressed data. The wrapper processor then must know how to retrieve
the unpacked size and the data from its own input stream.

> And use a 64-bit size and an endianness indicator if possible.

The 64 bit issue should be handled by the basic TStream class, where
also the according data types for size_t, off_t (or equivalent) should
be defined appropriately. The endianness of the target system also can
be selected at compile time - how?

> Search for "zfs" (zip filesystem). It was FPC compat for a while.

Can you be a bit more specific? I have traditional problems in searching
My first search resulted in >6000 hits, almost related to zip drives. My
second search retrieved two messages about errors in a StarKit...

> > I already
> > decided to replace my own "stdc" unit by the FPC "libc" unit, with
> > hopefully no changes to that unit.
> Then change them again to use BaseUnix/Unix :-)

I could locate 2 BaseUnix.pp units, for Linux and BSD. But I'm
developing under Windows :-(

What I really need is a unit with commonly used type names, so that all
modules ported from C to Pascal share the same types. The module
specific types are less important, because these are not shared with
other modules; nonetheless even these types should be defined based on
common types, like cUInt8.

> The "libc" unit is not a base unit of FPC, but exists merely for Kylix
> porting purposes, since it is pretty much only a direct x86 glibc
> translation, and not a general POSIX abstraction. It is only supported for
> Linux/x86.

Good to know. I already wondered how the implementation could work on

> As said, a portable subset is available in units baseunix/unix

Where? I couldn't find any such directory and unit in the FPC sources

A related question: which (source...) directories must I add to the
search path, for using FPC and (primarily) Lazarus on Windows?

> See  for some docs

Just downloaded, but I couldn't find neither on the server nor in the
expanded a /rtl directory.


fpc-devel maillist  -

Reply via email to