The African Chief wrote:

...

The problem with this one is that (at least on the common platforms), "long" is the same as "int", and I'd expect (as probably many ex-BP programmers do) LongInt to be longer than Integer. In fact, some of my programs rely on this.

Yes. But in BP, "integer" is 16-bit and "longint" is 32-bit. Surely, if your programs rely on "longint" to be bigger than "integer", they also expect "integer" to be 16-bit?

Not necessarily.

If GCC's "long" is 32-bit and GPC's "longint" is 64-bit - what does that say about compatibility of data structures?

E.g., that LongIntVar=LongInt(IntVar)*IntVar works always without overflowing, or that you can type cast a LongInt into a record of two Integers.

This is from the BPW help file;

"Note: The comp type is a 64-bit integer. It holds only integral values within the range (-2 63 + 1) to (2 63 - 1)."

I know that (except that I think it should be -2^63, not "+1"). What I don't understand is the strange name "Comp" -- which I still can't make any sense of in connection with integer data types.

And something I just noticed concerning "Word" (this is addressed more to Peter ;-) :

A "machine word" in the sense of assembly language actually describes the *size* of data and not whether it's signed or unsigned, doesn't it? (Data in asm are neither signed nor unsigned per se, it depends on which operations are used on them.) So from the original meaning (in PC real mode) "Word = 16 bits", Borland made "Word = 16 bits unsigned", and now you seem to be making "Word = unsigned" out of it...