pointer-compatibile integers (was: gpi-hash.c segfaults)

Thu, 31 Jul 1997 18:44:10 +0200 (MET DST)

According to Frank Heckenbach:
> 
> While we're at it: would it be possible to have predefined Pascal types
> as size_t and ptrdiff_t (and maybe other types?) so that such
> calculations can be done in Pascal?

Not enough integer types yet?  ;-)

This can be be implemented with

    Type
      PtrInt = Integer ( BitSizeOf ( Pointer ) );

Is this sufficient?  Since GPC fully supports pointer arithmetics,
I don't see too much applications for this.

If not ... what about `PtrInt', `PtrCard', and `PtrWord'?

Greetings,

    Peter


(* For those who have not followed the recent discussion about integer
types in GPC, here is some background:  Besides `Integer' (signed), GPC
supports `Cardinal' (unsigned) and `Word' (don't care about signedness,
in fact unsigned).  These types exist in several sizes which guarantee
compatibility to GNU C and introduce some portability to other Pascal
compilers:

    GNU Pascal          GNU C

    ByteInt             signed char
    ShortInt            short int
    Integer             int
    MedInt              long int
    LongInt             long long int

There are also `*Card' and `*Word' versions of these, yielding a total
of fifteen basic integer types.  Besides this, GPC supports a synonym
`LongestInt' for `LongInt' which guarantees the longest possible integer
type (for the case that GNU C introduces `long long long int' which
we would implement as `LongLongInt'); same with `LongestCard' and
`LongestWord'.  Eighteen.

Compatibility to Borland Pascal and Delphi requires `Comp' (same as
`LongInt' and `SmallInt' (same as `ShortInt' in GPC).  Twenty.

Okay?  Good.  Now it *really* begins.

Like all Pascal compilers, GPC supports subranges like `1..42'.  This
adds 2 * sqr ( 2 pow 64 ) more possible integer types to our zoo.
The `2' comes from signed and unsigned variants ... let's speak of
"20 + two classes" of integer types.  As an extension, GPC allows these
subranges to be `packed' (i.e. allocate only one byte for `packed 1..42';
the default of allocating four bytes results in faster code) which leaves
us with 20 + four classes of integer types.

In low-level programming you often have the situation that you want to
know exactly how many bits a variable occupies.  While this could be
done with packed subranges, it is more comfortable to have an extended
syntax for `Integer'.  In GPC, `Integer ( 42 )' yields a 42-bit integer.
Depending on the machine (which might not have 42-bit registers) this
will probably be stored in a 64-bit word, except in packed records;
however on those machines where you need, say, `Integer ( 8 )' for your
low-level stuff, you can be sure that the hardware supports it.  Having
this for `Cardinal' and `Word' as well yields 20 + 7 classes.

Adding `Ptr[Int|Card|Word]' as suggested above would make it
23 + 7 classes of integer types.  Well, no big deal.

I know this is a great source of confusion, but the discussion convinced
me that all these integer types have their place where they are important.

Greetings,

    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 [970714] - http://home.pages.de/~gnu-pascal/ [970125]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)