[fpc-devel] Portability Standards

[Michael Van Canneyt]

On Tue, 4 Jan 2005, DrDiettrich wrote:

> 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?

FPC and POSIX are totally unrelated.
Unix is a superset of POSIX. Most Unices out there are POSIX compliant.

POSIX says nothing about pascal, it's basically a C interface.

The FPC baseunix/unix units mimic more or less the POSIX standard, so
1. It would be easy to write Pascal code, based on C examples.
2. It can be mapped on Libc for porting purposes. If you port to a
   new platform, and it has a Posix-confirming C library, you will
   have little work to do.

>
> > > 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?

No. TStream. An archive stream does not have a handle.

>
> > > 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.

1. They are not "well-defined", but this is another story :-)
2. I absolutely HATE underscores in types/variables/whatever
   for documentation purposes it is a horror (I use TeX)

> 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...).

Sysutils, then.

>
> > The current implementation is done for compatibility with Delphi, and
> > for optimization.
>
> Hmm, compatibility with which Delphi version? ;-)

5 at least.

>
> 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.

You can send a list of such things to any core member.

>
> > > "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.

Cardinal = 32 bits _always_. Also on 64 bit.

>
> 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...).

The old are not subject to discussion.
You can introduce new ones in any way you see fit.

Rule number 1 when creating a new (big) Delphi project:
"Subclass ALL classes you will be needing."
Saves a lot of trouble afterwards.

Same rule applies here.

Michael.