[fpc-devel] Portability Standards

[DrDiettrich]

Michael Van Canneyt wrote:

> The FPC units are not POSIX, hence, UNIX.
> (long threads have already been spent on that, and it is a done deal)

I don't want to resurrect a discussion, but can somebody give me an idea
how UNIX and POSIX are different, with regards to FPC?

> > Question: What's preferrable, a direct port of the Abbrevia library, or
> > a new and better portable design instead, that interfaces with the not
> > otherwise available worker classes as implemented in Abbrevia?
> 
> Second option.

I have already started with a revival of my TXStream classes, now with
hopefully better portability. One problem are required changes and
extensions to the TStream base class. The new stream classes will be
either input or output streams, and will have I/O buffers used for
crypting and compression. What's the recommended base class herefore?
THandleStream?

> > 3) Data Types
> > "off_t" now replaces the Integer/LongInt/Int64 mess, for all file size
> > related values. I took this name from the C standard, but perhaps it
> > should be replaced by some Pascal name?
> 
> I think the best way - for now - is to define a set of basic types
> in some base unit:
> - TFileHandle
> - TSeekOffset
> - ...
> Which should be used consistently throughout the system.

That's why I choose the well defined C names for now, like size_t,
off_t.
off_t could be replaced by TFileSize, what's the reason for moving from
32 to 64 bit for huge files, whereas TSeekOffset also indicates that
this type must be signed for moves in both directions.
size_t must not necessarily become a new type. I used it for the amount
of data in Read and Write, where (signed) 32 bits are sufficient on 32
bit machines, with regards to buffer size in memory.

> These base types can then be mapped on a per-os basis to whatever fits best.
> (or to basic FPC types, when (not if!) FPC introduces them.

The best base unit IMO is where the low level I/O procedures are
defined, which wrap the OS I/O calls (FileRead...).

> The current implementation is done for compatibility with Delphi, and
> for optimization.

Hmm, compatibility with which Delphi version? ;-)

Apropos optimization, in many FPC units I found constructs like:
  if x = 0 then f(0) else f(x)
In these cases the IF is superfluous.

> > "DWORD" will be replaced by cUInt32 (or equivalent - what?), as far as
> > this type is used outside dedicated MSWINDOWS code.
> 
> The native pascal type is 'Cardinal'. But see the remark about basic types.

DWORD often is used for exactly 32 bits, so that Cardinal is not an
appropriate replacement.

Perhaps we should discuss the (new and old) data types explicitly, for a
precise description of the intended use, naming, and general properties
(signedness, fixed or minimum bit size...).

DoDi