[fpc-devel] Portability Standards

[DrDiettrich]

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:

In the first place a DEBUG symbol allows to replace everything else by
another AbDebug.inc file. This switch will allow (me) to define the OS
etc. at will, for debugging purposes. Defining this symbol and the file
contents is entirely up to the user, the file will not occur in CVS or
any distribution.

In the next place the FPC symbol is used to replace the Borland specific
part by an AbFpc.inc file. This file, with an appropriate name, can be
contributed by some FPC user, I don't care for this conditional branch
for now.

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?

Question: How to use the FPC provided target symbols?
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.
I'm also not familiar with the differences between the Unix/POSIX
systems. Currently I make no according differences myself, I only
separate the existing code into conditional MSWINDOWS and UNIX parts.


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?

It may be desireable to use another dedicated unit for strictly platform
dependent procedures, apart from AbUtils?

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?

A direct port IMO requires more work than a redesign.
In a redesign also much Windows/Delphi/Kylix specific stuff could be
removed or replaced by more portable procedures. The entire file
handling stuff in Abbrevia IMO is too Windows-centric, the Linux/Kylix
extensions only are patchwork that tries to map the Windows file
handling to the very different POSIX file handling, what can result in
loss of file attributes on POSIX platforms.


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

"DWORD" will be replaced by cUInt32 (or equivalent - what?), as far as
this type is used outside dedicated MSWINDOWS code.

The 16 bit "word" datatype IMO should not be used in 32 bit code, unless
where required in datastructures with a fixed layout.

Similar considerations and decisions will be required during porting, I
only presented these examples as a concrete base for a general
discussion.


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.

For the same reasons I think that public error codes only should be
specified for those error conditions that can or must be handled in some
specific way. These common codes then should be used by all
de/compressor classes.

DoDi