Re: Ada Pointer Size Problem

[Stephen Leake <stephen_leake@acm.org>]

aschwarz@acm.org (skidmarks) writes:

> I have a problem with the test program below. Perhaps someone can help me.
> 
> 1. P1_Size gives an error. P2_Size and P3_Size don't. 
>    I would have expected errors everywhere or nowhere.
>    I don't understand what is 'non-static' about the
>    expression since a typedef is invariant.

Gnat 5.02a1 says:

junk.adb:9:35: non-static expression used in number declaration
junk.adb:9:45: size attribute is only static for scalar type (RM 4.9(7,8))
junk.adb:13:35: non-static expression used in number declaration
junk.adb:13:54: "P2_Size" is not static constant or named number (RM 4.9(5))

In general 'static' means "known at compile time", but the details in
the RM sometimes deviate from that simple description. The reasons
have to do with making the compiler easier to right, mostly. I think
Ada 2005 will be making more things static.

> 3. The string pointer size (eliding the error statements)
>    is 64-bits. I am using an AMD 2100 (32-bit) computer
>    and gcc-3.3.3-3. I would have expected a 32-bit
>    pointer. 

Just shows the compiler knows better than you do :).

A pointer to an unconstrained array also needs a 'dope vector', that
stores the bounds of the array.

> 4. The integer pointer size (eliding the error statements)
>    is 32-bits. I would have expected that it would be the
>    same size as the string pointer.
> 
> I've looked at the 'info' tex file included with the 
> gcc distribution and so far have not found how to 
> change a 64-bit pointer to a 32-bit pointer. 

Why do you want to do that? A pointer to an integer is not a pointer
to a string.

> I've thought that maybe I am getting the dope vector size associated
> with the String_Ptr but this really doesn't make sense. 

Why doesn't that make sense?

> The Integer_Ptr is only 32-bits which seems to be correct but both
> pointers should be the same.

Why?

-- 
-- Stephe