Ada Pointer Size Problem
skidmarks
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.
2. 'thang' (L13) is erroneous but 'Variable' (L17) is
not. I suspect that this means that the non-static
nature of the expression is OK as a statement but
not in a definition.
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.
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. I've
thought that maybe I am getting the dope vector size
associated with the String_Ptr but this really doesn't
make sense. The Integer_Ptr is only 32-bits which
seems to be correct but both pointers should be the
same.
Any idea of what I'm really missing?
art
--------------------------------------------------------
# compiling under Cygwin on a Windows 2000, AMD 2100 CPU
# gcc-3.3.3-3
>> gcc -c -gnatfv -gnatl junk.adb
GNAT 3.3.3 (cygwin special)
Copyright 1992-2002 Free Software Foundation, Inc.
Compiling: junk.adb (source file time stamp: 2004-10-10 19:50:18)
1. with Text_IO; use Text_IO;
2.
3. procedure junk is
4. type String_Ptr is access all String;
5. type Integer_Ptr is access all Integer;
6.
7. In_Size : constant := Integer'Size;
8. Fl_Size : constant := Float'Size;
9. P1_Size : constant := String_Ptr'Size;
|
>>> non-static expression used in number declaration
10. P2_Size : Integer := String_Ptr'Size;
11. P3_Size : constant Integer := String_Ptr'Size;
12. thing : constant := Integer'Max(In_Size, Fl_Size);
13. thang : constant := Integer'Max(thing, P2_Size);
|
>>> non-static expression used in number declaration
14. Variable : Integer;
15.
16. begin -- junk
17. Variable := Integer'Max(In_size, String_Ptr'Size);
18. Put_Line("Integer = " & Integer'Image(Integer'Size) ); -- 32 bits
19. Put_Line("Float = " & Integer'Image(Float'Size) ); -- 32 bits
20. Put_Line("Int_Ptr = " & Integer'Image(Integer_Ptr'Size)); -- 32 bits
21. Put_Line("Ptr = " & Integer'Image(String_Ptr'Size)); -- 64 bits
22. Put_Line("Ptr1 = " & Integer'Image(P1_Size)); -- 64 bits
23. Put_Line("Ptr2 = " & Integer'Image(P2_Size)); -- 64 bits
24. Put_Line("Ptr3 = " & Integer'Image(P3_Size)); -- 64 bits
25. Put_Line("Variable= " & Integer'Image(Variable)); -- 64 bits
26. end junk;
26 lines: 2 errors
>>
Stephen Leake
> 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
Jeffrey Carter
> 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.
The first question, as always, is why you're using access types, and why
you care how the compiler represents them. As an apparent beginner in
Ada, you should not need access types, unless you're doing an assignment
on dynamic data structures.
String_Ptr isn't a pointer; it's an access type. As pointed out in
another thread, access values are not necessarily pointers, and that's
why they're not called pointers. In this case, the extra space is
probably connected to the bounds information needed for the array.
> Any idea of what I'm really missing?
Probably the difference between pointers in simple languages and access
values in high-level languages. In C/++, a pointer is an int is an
address. In Ada, they're 3 different things.
--
Jeff Carter
"Don't knock masturbation. It's sex with someone I love."
Annie Hall
45
Martin Krischik
> I have a problem with the test program below. Perhaps someone can help me.
Well an access is not a pointer. System.Address is a pointer. There are
functions to convert an access to an Address..An access may contain
additional informations apart from the pointer - like size of the object
pointed to (for indefinite objects), a reference counter (for access all or
anonymous access) etc. pp.
> 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
The System package has the needed convetion functions.
With Regards
Martin
--
mailto://kris...@users.sourceforge.net
http://www.ada.krischik.com
skidmarks
> asch...@acm.org (skidmarks) writes:
> > 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 misspoke, perhaps sarcastically. I don't want to change pointer sizes
and you have gone far to explain what I'm seeing. Although the reason
for including the dope vector as part of an Access Type eludes me, the
explanation I understand. (The elusion is because it seems just as
reasonable to 'point' to a dope vector when specifying an access type
rather than including the dope vector as the Access Type.) Albeit,
thanks to all for the clarification between System.Address and Access
Type.
>
> > I've thought that maybe I am getting the dope vector size associated
> > with the String_Ptr but this really doesn't make sense.
>
See above. To resolve this (type of) difficulty locally - for Ada83
interfaces to C primarily, we do the following:
A_Access := array'Access
B_Pointer := array(array'First)'Address
and for the purists, THIS IS NOT TRUE ADA, so don't flame me because
it's not true Ada.
> 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?
See above.
And to all, thanks. You have clarified the issues.
art
Jeffrey Carter
>
> A_Access := array'Access
> B_Pointer := array(array'First)'Address
I realize this is conceptual, not code, but this is not Ada-83 like. In
Ada 95, you can declare an access type to have convention C:
type Str_Ptr is access all String;
pragma Convention (C, Str_Ptr);
Str_Ptr will be a pointer in the C sense. In Ada 83, System.Address and
'Address is usually appropriate.
--
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81
Martin Krischik
> Stephen Leake <stephe...@acm.org> wrote in message
> news:<mailman.269.10974587...@ada-france.org>...
>> asch...@acm.org (skidmarks) writes:
>
>> > 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 misspoke, perhaps sarcastically. I don't want to change pointer sizes
> and you have gone far to explain what I'm seeing. Although the reason
> for including the dope vector as part of an Access Type eludes me, the
> explanation I understand. (The elusion is because it seems just as
> reasonable to 'point' to a dope vector when specifying an access type
> rather than including the dope vector as the Access Type.) Albeit,
> thanks to all for the clarification between System.Address and Access
> Type.
Actually the compiler vendors are free to choose the implementation thats
suits them best.
>> > I've thought that maybe I am getting the dope vector size associated
>> > with the String_Ptr but this really doesn't make sense.
>>
>
> See above. To resolve this (type of) difficulty locally - for Ada83
> interfaces to C primarily, we do the following:
>
> A_Access := array'Access
> B_Pointer := array(array'First)'Address
>
> and for the purists, THIS IS NOT TRUE ADA, so don't flame me because
> it's not true Ada.
I use this trick as well from time to time in Ada 95. It's faster and saves
memory.
Even cooler:
type Ada_String is String (1.. C_String_Len);
for Ada_String'Address use C_String'Address;
With Regads
Dmitry A. Kazakov
> Martin Krischik <kris...@users.sourceforge.net> wrote in message news:<1404015.d...@linux1.krischik.com>...
> Are there also functions that convert an Address to an access?? And
> what about Ada's type safety than ??
The reset button is always at your service, then! (:-))
> I also can't anything about System.Address in the Ada95RM, a leftover
> from Ada83?
See ARM 13.7.2
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Steve
for.
http://www.adaic.org/standards/95lrm/html/RM-13-7-2.html
Steve
(The Duck)
"Hans Van den Eynden" <onsb...@hotmail.com> wrote in message
news:1c2f5137.0410...@posting.google.com...
>[snip]
>
> > There are functions to convert an access to an Address
>
> Are there also functions that convert an Address to an access?? And
> what about Ada's type safety than ??
Jean-Pierre Rosen
> I misspoke, perhaps sarcastically. I don't want to change pointer sizes
> and you have gone far to explain what I'm seeing. Although the reason
> for including the dope vector as part of an Access Type eludes me, the
> explanation I understand. (The elusion is because it seems just as
> reasonable to 'point' to a dope vector when specifying an access type
> rather than including the dope vector as the Access Type.)
It is not always possible to have the dope just before the array.
For example, you can point to a slice of a string...
--
---------------------------------------------------------
J-P. Rosen (ro...@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
Dave Thompson
wrote:
> skidmarks wrote:
<snip: access types versus addresses>
> > Any idea of what I'm really missing?
>
> Probably the difference between pointers in simple languages and access
> values in high-level languages. In C/++, a pointer is an int is an
> address. In Ada, they're 3 different things.
This is overstating the case.
In C a pointer value is in practice just an address. This isn't
formally required, but traditionally it's so; the standard specifies
(intentionally) semantics that allow it; and anything else is
unacceptably (to most users) inefficient, since C requires many array
accesses -- thus including character strings -- to go through
pointers, and all pointers of a given type to be the same -- unlike
non-all access or PL/I OFFSET.
But (unlike its predecessor B) a C pointer/address is not just an int.
It has addition and subtraction, but scaled by the target size
(stride) -- and standardly only required to work within a single
variables; there is not required to be a flat address space, although
that is common and some C program/mers unportably rely on it. Other
operations which would be meaningless like multiply and divide are
prevented, and conversions are explicit, like System.Address.
In C++ the same is true for builtin/standard pointers, but the
standard library provides a number of enhanced pointer-like types that
can be used transparently, and you (or someone) can write your own.
- David.Thompson1 at worldnet.att.net
Jeffrey Carter
> On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <sp...@spam.com>
> wrote:
>>
>> In C/++, a pointer is an int is an address. In Ada, they're 3
>> different things.
>
> But (unlike its predecessor B) a C pointer/address is not just an
> int.
I meant that a pointer is an int because you can always convert/assign a
pointer to an int.
--
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72
Martin Krischik
> Dave Thompson wrote:
>
>> On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <sp...@spam.com>
>> wrote:
>>>
>>> In C/++, a pointer is an int is an address. In Ada, they're 3
>>> different things.
>>
>> But (unlike its predecessor B) a C pointer/address is not just an
>> int.
>
> I meant that a pointer is an int because you can always convert/assign a
> pointer to an int.
Not on a 64 bit CPU. Most 64bit compiler have not expanded int to 64 bit (as
they should have done). Only "intptr_t" and "uintptr_t" are large enough to
store a pointer.
If you use MS-C then activate /W64 and see what happens.
With Regards
Jeffrey Carter
> If you use MS-C then activate /W64 and see what happens.
I don't use C, and am speaking from several-year-old memory. Every C
I've ever used allowed a pointer or address to be stored in an int.
--
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
14
Simon Wright
> Dave Thompson wrote:
>
> > On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <sp...@spam.com>
> > wrote:
> >> In C/++, a pointer is an int is an address. In Ada, they're 3
> >> different things.
> > But (unlike its predecessor B) a C pointer/address is not just an
> > int.
>
> I meant that a pointer is an int because you can always convert/assign a
> pointer to an int.
I'm pretty sure that on Alphas (this was OSF/1 unix) a pointer was a
long (64 bits) while an int was 32 bits .. so, assign away, just don't
expect things to work portably for ever!
--
Simon Wright 100% Ada, no bugs.
Martin Krischik
> Martin Krischik wrote:
>
>> If you use MS-C then activate /W64 and see what happens.
>
> I don't use C, and am speaking from several-year-old memory.
Well, /W64 works for MS-C++ as well.
> Every C
> I've ever used allowed a pointer or address to be stored in an int.
Then you have used C only in a very small windows of opportunity. You have
missed the intersting world of the 80286 with it's host of very interesting
memory models.
And you have not yet arrived the great new world of 64 bit computing - where
a pointer is twice the size of an int.
Adrien Plisson
> Jeffrey Carter wrote:
>>Every C
>>I've ever used allowed a pointer or address to be stored in an int.
>
> Then you have used C only in a very small windows of opportunity. You have
> missed the intersting world of the 80286 with it's host of very interesting
> memory models.
in C and C++ on most 32 bits platforms:
sizeof( void *) == sizeof( long ) == sizeof( int ) == 4
that's why he is allowed to store pointers in an int. to use 64 bit wide
integers, you have to use __int64.
so I don't think he missed the 80286 and its bunch of wonderful memory
models...
> And you have not yet arrived the great new world of 64 bit computing - where
> a pointer is twice the size of an int.
well, we have to get prepared for the future world of 128 bit computing.
coming sooner or later to a computer near you !
--
rien
Warren W. Gay VE3WWG
> Martin Krischik wrote:
>> Jeffrey Carter wrote:
>>> Every C I've ever used allowed a pointer or address to be stored in
>>> an int.
>>
>> Then you have used C only in a very small windows of opportunity. You
>> have
>> missed the intersting world of the 80286 with it's host of very
>> interesting
>> memory models.
>
> in C and C++ on most 32 bits platforms:
> sizeof( void *) == sizeof( long ) == sizeof( int ) == 4
> that's why he is allowed to store pointers in an int. to use 64 bit wide
> integers, you have to use __int64.
...
> well, we have to get prepared for the future world of 128 bit computing.
> coming sooner or later to a computer near you !
This brings up an interesting point WRT Ada: since much C/C++
code has depended upon this relationship and Ada does not (though
it can be abused). Ada code in this respect at least, should more
easily adapt to platforms with increasing sizes of address spaces.
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg
Mark Lorenzen
> Dave Thompson wrote:
>
> > On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <sp...@spam.com>
> > wrote:
> >> In C/++, a pointer is an int is an address. In Ada, they're 3
> >> different things.
> > But (unlike its predecessor B) a C pointer/address is not just an
> > int.
>
> I meant that a pointer is an int because you can always convert/assign a
> pointer to an int.
You can do that in Ada also. See ARM 3.7.1.(10) and 3.7.1.(13). This
does of course not mean that a value of type Address is an integer
subtype.
- Mark Lorenzen
Jeffrey Carter
> Well, /W64 works for MS-C++ as well.
I don't use C-incremented, either.
> Then you have used C only in a very small windows of opportunity. You
> have missed the intersting world of the 80286 with it's host of very
> interesting memory models.
I have indeed avoided using C on most platforms.
> And you have not yet arrived the great new world of 64 bit computing
> - where a pointer is twice the size of an int.
Actually, I started my career in professional software development in
the world of 60-bit computing, with 120-bit double-precision
floating-point values. Most processors since then have seemed sort of
like a step backwards. However, they cost a lot less and didn't take up
most of 2 floors at the university computer center.
--
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19
Martin Krischik
> Martin Krischik wrote:
>> Jeffrey Carter wrote:
>>>Every C
>>>I've ever used allowed a pointer or address to be stored in an int.
>>
>> Then you have used C only in a very small windows of opportunity. You
>> have missed the intersting world of the 80286 with it's host of very
>> interesting memory models.
>
> in C and C++ on most 32 bits platforms:
> sizeof( void *) == sizeof( long ) == sizeof( int ) == 4
> that's why he is allowed to store pointers in an int. to use 64 bit wide
> integers, you have to use __int64.
Only the the computers I bought recently are 64 bit and - if you belive in
Moors law - transition to greater 2 GB of main memory for general use
should happen within the next 18 month.
BTW: You should store pointers in intptr_t or uintptr_t.
And you should not use datatypes which start with two "_" - If you need 64
bits you should use int64_t.
> so I don't think he missed the 80286 and its bunch of wonderful memory
> models...
There was a bit of sarcasm on my side here.
>> And you have not yet arrived the great new world of 64 bit computing -
>> where a pointer is twice the size of an int.
>
> well, we have to get prepared for the future world of 128 bit computing.
> coming sooner or later to a computer near you !
Well Moors law demands an additional bit ever 18 month. So PC's will need
128 bit address space in about 24 years. Workstations, Server etc. pp. a
little sooner.
Martin Krischik
> Martin Krischik wrote:
>
>> Well, /W64 works for MS-C++ as well.
>
> I don't use C-incremented, either.
After more the 10 years of C++ I do envy you.
>> Then you have used C only in a very small windows of opportunity. You
>> have missed the intersting world of the 80286 with it's host of very
>> interesting memory models.
>
> I have indeed avoided using C on most platforms.
You are a very lucky man that you could make that decision.
>> And you have not yet arrived the great new world of 64 bit computing
>> - where a pointer is twice the size of an int.
>
> Actually, I started my career in professional software development in
> the world of 60-bit computing, with 120-bit double-precision
> floating-point values. Most processors since then have seemed sort of
> like a step backwards. However, they cost a lot less and didn't take up
> most of 2 floors at the university computer center.
<grin>
Dave Thompson
wrote:
> Dave Thompson wrote:
>
> > On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <sp...@spam.com>
> > wrote:
> >>
> >> In C/++, a pointer is an int is an address. In Ada, they're 3
> >> different things.
> >
> > But (unlike its predecessor B) a C pointer/address is not just an
> > int.
>
> I meant that a pointer is an int because you can always convert/assign a
> pointer to an int.
Well, in many languages (not just C) you can just assign an integer
(or fixed-point) value to floating-point and vice versa, but I sure
wouldn't say that either "is" the other.
And you can't assign C pointer to integer without conversion; it
violates a constraint. (Or pass as parameter or return as value, since
in C those are always semantically equivalent to assignment.)
You can write the conversion to any integer type explicitly with a
cast, but the result is implementation-defined and may or may not be
useful. For most mainstream systems there is a simple and useful
mapping and that is what any sensible implementation provides, but the
Standard doesn't require it.
As others have already said, the specific type 'int', which is only
one of the integer types provided by a conforming C, need not be large
enough to handle (all) addresses. In addition to the 286 example, I
have long personal experience of the "classic" (that is, pre-RISC,
still used in emulation) Tandem^WCompaq^WHP NonStop, with three
execution models: IP16, I16P32, and IP32; corresponding basically to
different stages in their CPU/ISA evolution. In the "large" I16P32
model obviously pointer in int doesn't work.
The new-in-C99 names intptr_t and uintptr_t are integer types
guaranteed large enough to losslessly store (with the explicit
conversion) any (data) pointer, but are optional; an implementation
need not provide them if it doesn't have a suitable integer type. As
with all the new <stdint.h> types, there is an associated preprocessor
macro you can test to determine if the type is present, and thus write
code that works-around the omission or at least fails gracefully --
but only with the ugliness typical of preprocessor solutions, as often
discussed here. But machines that actually can't do address arithmetic
-- and thus reasonably support such an integer type -- are for obvious
reasons pretty damn rare if they exist at all, and also (would be)
very unlikely to be able to support the rest of C anyway.
- David.Thompson1 at worldnet.att.net