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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel