According to Orlando Llanes:

The only reason I suggested having Platform specific types is because since the size varies per system, and you save a file using natural types on one, they have to be read in using the same size. For example, let's say a Word is 32-bit on one system, and then you have the PC where it's 16-bit, let's call them Word (32-bit) and PCWord (16-bit).

The natural size of a Word on the PC equipped with a 80386 or higher is 32-bit. The restriction of most applications to 16 bits is an artificial one and orginates to Microsoft which did not react on the hardware improvement. We do.

Word is 4 bytes, PCWord is 2 bytes. If data was written using PCWord, it could be read into a Word. But if a Word was written, then it needs 2 PCWords to read it properly. In this way, it's not cross platform because you have to make adjustments per platform.

So what you are really worrying about is the binary format (which includes the size) of these types, not the platform where they are "natural". I agree. This means that the following is the way to go:

I'm all for the IntX data types suggested earlier for this reason, if one data type is treated the same across all platforms, then all you have to do is write a program once, and then compile it across all platforms without having to use platform specific compiler options. [...]

So it's clear what has to be implemented. Now we must discuss about their syntax.

Where do such data types matter? Everywhere where we must set up a record type of well-known size and structure, for example when reading a binary file created by some other program, or when communicating with the operating system.

For this reason, the syntax must be compact, and somehow closer to the bare metal (assembler) than to the clouds (Modula). That's why I prefer `Word' here with respect to `Cardinal'. (* Another reason is that when I read `Card', I think of games, not of cardinalship. ;*) (Due to the need for compactness, I think my "Integer ( 8 )" notation was not the best idea. Or perhaps it was, and the programmer can define the below in his own Units?) So what about this?

Int8 Word8 = Byte Int16 Word16 Int32 Word32 Int64 Word64

Once more discussing subranges as an alternative: "True Pascal" does not specify the storage size, but valid values for those. So I am no more sure whether it is wise to guarantee that their size will always be the minimal one. And anyway, they are no true replacement for built-in data types of well-defined size because no programmer will write `0..$FF' everytime he wants to express that something has 8 bits. He will define his own type for this reason: "Type Byte = 0..$FF". (Note that `Byte' is built-in in GPC!) If we don't want terrible confusion among future GPC hackers, we should provide built-in types for such purposes.

The other thing we must worry about is compatibility to GNU C, because the use of GNU Pascal depends on library written in GNU C. For this reason, `ShortInt', `ShortWord', `ByteInt', and `Byte' must stay like they are; I think it's quite natural then to have `Word' for an unsigned 32-bit Integer. I am not sure whether `int' in GNU C might ever change to be different from `long int'. (DOES SOMEBODY KNOW???) If so, our (my;) choice for the meaning of `LongInt' and `LongWord' might be subject to change. (Note again that I am speaking about types that *are* built-in in GPC with the mentioned meanings.)

Peter

Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]