[fpc-devel] Portability Standards

[Michael Van Canneyt]

On Sun, 2 Jan 2005, DrDiettrich wrote:

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

This seems good.

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

That would be preferable.

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

Nothing other than 'verX' (replace x with 14,15 or 16) and Linux...


> Question: How to use the FPC provided target symbols?
> I'm not happy with the UNIX keyword, I'd used POSIX instead.

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

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

This is good.

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

{$ifndef unix}
{$i abiuwin.inc} // more to follow later: e.g. Mac OS, Netware etc.
{$else}
{$i abiulin.inc}
{$endif}

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

If there are a lot: yes, otherwise, I think they could

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

Second option.

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

Agreed.

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


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

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

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

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

Agreed.

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

Yes and no. You can use exceptions perfectly for aborting code.
It is a common misconception to think that an exception always
signals an error condition. Of course, the code must then know
which exceptions are error conditions and which not.

But normally, I agree that you don't need too many exception classes.
1 or 2 with an error code field (if needed at all) should be enough.

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

Agreed.

Michael.