[fpc-devel] integer, cardinal

Vinzent Hoefler JeLlyFish.software at gmx.net
Mon Apr 18 10:40:20 CEST 2005


On Monday 18 April 2005 07:29, Peter Vreman wrote:
> > On Sunday 17 April 2005 10:45, Ales Katona wrote:
> >> First of all Integer should be size independent, that is, xy bits
> >> depending on the platform.
> >
> > I second that.
>
> This is useless. Your code

That doesn't matter. If I'd want the same code on all platforms I'd use 
Java.

> and runtime checks

That can indeed be a problem, especially when this size is used in 
intermediate calculations (in correct programs, it should not have an 
effect on the result or you are out of luck already. Go fix your code 
then.).

> will then vary for the
> kind of processor (32 or 64bit) you are compiling for.

That's some of the reasons I personally discourage using such types 
unless perhaps for loop-counters where you know it will never overflow 
some way or another.

> Even 'int' in C is always 4 bytes.

Huh? Since when? Last time I checked the C99 standard, int was only 
guaranteed to be able to hold the values -32767 to 32767 and that makes 
"int" at best a "must at least be 16 bit"-type. C doesn't even specify 
that that thing they call "byte" is actually the usual 8-bits wide.

> The 'long' type is most of the time equal to the
> size of a pointer.

You say it: "Most". And on platforms where it doesn't (and I know some), 
code that relies on that will break. So someone would be better off to 
assume nothing about such types. The problem in C is: there are no 
range types, you are _bound_ to use some of the predefined ones.

> Don't expect that we change anything in this part. If you want to use
> an integer with the natural size of the processor you can use ptrint
> or ptruint.

I think that's a bad suggestion and you know it.

Oh, but while we're at it: fpc1.9.6 still gives me the Hint, that this 
PtrUInt/Address-Conversion isn't portable:

|         WriteLn ('Runtime error ', ExitCode,
|                  ' at 16#',
|                  SysUtils.IntToHex (PtrUint(ErrorAddr),
|                                     2 * SizeOf (ErrorAddr)),
|                  '#');

Is that fixed in the current version? Or am I thinking wrong when I 
think, this should - by definition - be portable? ;-)


Vinzent.





More information about the fpc-devel mailing list