[fpc-devel] Portability Standards

[Marco van de Voort]

> Michael Van Canneyt wrote:
> 
> > > 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. ;-)
> 
> Here some comments and questions about the Abbrevia port.
> 
> 1) Conditionals
> I've redesigned the AbDefine.inc file, with two important changes:

You might also want to have a look at 

http://www.stack.nl/~marcov/porting.pdf

and 

http://www.stack.nl/~marcov/unixrtl.pdf
 
> Question: Rename all files? All lowercase...?
> 
> The LINUX symbol can clash with the according FPC symbol. It should be
> renamed e.g. into KYLIX - does somebody know what Kylix defines for
> itself?

A combination of ver<x> and linux, as Michael said.
 
There are 4 cases for Unix:

1 Kylix
2 FPC/Linux/x86 reusing Kylix libc code.
3 FPC/Linux/x86 using general FPC unix code
4 Other FPC Unix targets using general FPC unix code

Since 1->2 is an easy port often, so I think in general FPC/Linux/x86 should
remain switchable between "libc" and "FPC-UNIX" mode.

> Question: How to use the FPC provided target symbols?

See the "porting" guide. I try to adhere to it, and so does JEDI.

> I'm not happy with the UNIX keyword, I'd used POSIX instead. But that's
> only my opinion, I don't want to introduce another symbol.

As Michael said, that was already discussed.

> I'm also not familiar with the differences between the Unix/POSIX
> systems.

Unix is supposed to be a superset. However one of the main reasons is to
avoid standards picking.

> 2) File Restructuring
> I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS
> and UNIX sections, each containing complete procedures. These sections
> could be moved into dedicated OS specific include files - what's the
> preferred way?

I (and FPC in general) prefer that. Jedi prefers to ifdef ad infinitum,
they are (used to be is a better word) afraid of include files.
 
> According to my first impression of the Abbrevia coding conventions I'd
> prefer to use the existing and better ported and portable code in the
> already existing paszlib and bzip2 libraries, instead of porting the
> according Abbrevia implementations. Perhaps the whole de/compressor part
> of Abbrevia could be reduced to the base classes, from which inherit the
> new wrappers for the FPC ports.
> 
> 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?

Since the answer varies wildly with the amount of work the implementor
wants to invest, I guess my answer would be "that is up to the implementor".

To me, a clean interface with zlib that is switchable between shared lib and
paszlib is a pre. I always liked that in the old situation. Partially also
because paszlib is still slower.
 
> 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?

FPC still got to acquire a native form of 64-bit filesupport. I think
using an identifier that is not likely to clash with existing types is
preferable. So that rules out off_t (which is used by Unix internally).

Later when FPC has a system for 64-bit fs, we can assign the type to
an invariant that has the right size for FPC's filesystem. (64-bit on
new systems, 32-bit on legacy)

> IMO this type also should be used in the TStream classes, replacing the
> current conditional distinction (seek64bit) between 32 and 64 bit
> methods. Why write two implementations, when the compiler can use the
> actual type definition immediately?

I'm in favour of simply making the whole FPC file implementation 64-bit,
regardless of 64-bit OS support or not.
 
> "DWORD" will be replaced by cUInt32 (or equivalent - what?), as far as
> this type is used outside dedicated MSWINDOWS code.

On *nix, the unixtype unit defines these.
 
> The 16 bit "word" datatype IMO should not be used in 32 bit code, unless
> where required in datastructures with a fixed layout.

True.
 
> 4) Exceptions, Error Codes etc.
> IMO it would be sufficient to use one general exception class for the
> de/compression errors. An application cannot draw any advantage from
> many specialized exception classes, and exception handlers inside a
> specific class can use the class specific error code in the exception
> object.

I think it would wise to not use exceptions too deep in the code.
Compression is one of those things where OOP and exception overhead still
count.