Word types..._(re)

Sat, 21 Jun 1997 15:44:07 +0200

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...
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
Turbo Pascal:   http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)