On Fri, 20 Jun 1997 15:49:30 +0200 Frank Heckenbach heckenb@mi.uni-erlangen.de wrote:
The African Chief wrote:
long longint {now = integer} unsigned long longword {now = word}
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? If GCC's "long" is 32-bit and GPC's "longint" is 64-bit - what does that say about compatibility of data structures?
long long comp {now = longint, or comp} unsigned long long compword (now = longword}
Why "Comp"? What does "Comp" mean at all? -- I really don't know, perhaps I could look it up in one of the 11 BP books... :-|
However, I don't think "Comp" is reasonable name for any integer type, except for BP compatibility ("Comp" = "compatibility type" ;-).
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)."
However, since the above will most likely break a lot of existing code, perhaps GPC should have built-in data types that mean *exactly* the same thing as they mean in GCC
Seems necessary. (I didn't like how C messed up their integer types, now we're getting the same problems... :-( -- I hope we find a good solution finally!)
So do I. The solution may be to predefine these types in GPC;
"int", "short", "long", "uint", "ulong", "ushort", "longlong", "dword", etc.
These could be defined to mean exactly the same thing as they mean in GCC - thus, there will be no need to "translate" them into Pascal.
Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk