[fpc-devel] Portability Standards

[DrDiettrich]

Michael Van Canneyt wrote:

> > 1) Target Dependencies

> Agreed 100%.
> In general, a component suite should have all os-dependent code in a single
> unit, presenting the rest of the suite with a uniform API.

Fine :-)
But how should that code be implemented? For various target platforms?


> > 2) Code Checks

> Why, you can simply cross-compile ?

No, I can't, neither in Delphi nor (AFAIK) in the Windows version of
fpc.


> > 3) Standard Units

> Compiler defines the endianness.

Correct, but this definition must be evaluated to produce the
appropriate code. E.g. RPM defines a function htonl, read:
HostToNetworkLong, that then is used to convert Long values in Network
byte order (big endian?) into the Host byte order. Such a function
should reside in a common unit, where the according implementation
depends on the endianness of the host machine. It also should have an
handy name, so that it's almost obvious how to replace htonl in the
ported code.

> System unit has 'guaranteed' types.

Fine, but these names often are not very descriptive, like ShortInt and
SmallInt. Names like cUInt16 make it more obvious that this type has a
fixed size and is unsigned.  More standard C names have to be mapped to
the predefined types. E.g. in Abbrevia the file size type (IMO)
initially has been Integer, later was conditionally extended to LongInt
and then to Int64, depending on the capabilities of the compiler and
platform. Here it can be seen that a replacement of some type by the
currently appropriate System standard name is not a good idea. A
distinct data type like off_t (standard C) would make all related
adaptations much simpler, with exactly one definition of that data type.

> > - OS specific data types and procedures
> 
> ? This is not portable.

When porting code, that was written for a specific platform, the names
of the procedures and related data types should not be changed. Instead
these procedures should be declared in a general unit, together with the
according implementations for other platforms. Please note the different
handling of OS functions and types, where the names should not be
changed, in contrast to the htonl function mentioned above, that should
be renamed to the according (to be defined) common procedure name.

> > The best compromise might be a mix of both methods. The interface can be
> > fully procedural, and objects with virtual methods are used only in the
> > implementation part, and only when this approach makes sense. Perhaps
> > somebody finds another way to achieve the same goal, with less
> > disadvantages?
> >
> 
> I don't think you should worry about virtuals.

I don't worry at all, but many people (assembler freaks...) will. That's
why I want to collect opinions before proceeding.

> For archiving purposes,
> it's the compression/decompression algorithms that will take most time,
> and tha actual reading/writing from stream.

This is an rather obvious case, but there exist other cases...


> > I'm willing to demonstrate my ideas in a redesign and extension of
> > Abbrevia, so that we have a concreter base for further discussions. But
> > before starting with that work I would like to hear some encouraging <g>
> > opinions or suggestions.
> 
> I think you can do this. I will be pleased to help where I can.
> But send a proposal before you start, I wouldn't want to you
> end up rewriting half your code after a discussion. ;-)

After a closer look at Abbrevia I'm not sure whether it's a good example
for porting code. The recent Kylix extension is crap, and also the
preceding conversions into Windows specific procedures and Pascal
standard types must be reverted to the original definitions. That's why
I'd prefer to use the better ported and portable code from e.g. zlib and
bzip2, instead of again porting the according miserable code from
Abbrevia. More to follow...

DoDi