* Ada Pointer Size Problem @ 2004-10-10 19:50 skidmarks 2004-10-11 1:38 ` Stephen Leake ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: skidmarks @ 2004-10-10 19:50 UTC (permalink / raw) 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. 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 >> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-10 19:50 Ada Pointer Size Problem skidmarks @ 2004-10-11 1:38 ` Stephen Leake 2004-10-12 18:44 ` skidmarks 2004-10-11 5:18 ` Jeffrey Carter 2004-10-11 8:45 ` Martin Krischik 2 siblings, 1 reply; 23+ messages in thread From: Stephen Leake @ 2004-10-11 1:38 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-11 1:38 ` Stephen Leake @ 2004-10-12 18:44 ` skidmarks 2004-10-13 1:23 ` Jeffrey Carter ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: skidmarks @ 2004-10-12 18:44 UTC (permalink / raw) Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.269.1097458704.390.comp.lang.ada@ada-france.org>... > aschwarz@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-12 18:44 ` skidmarks @ 2004-10-13 1:23 ` Jeffrey Carter 2004-10-13 8:07 ` Martin Krischik 2004-10-13 16:27 ` Jean-Pierre Rosen 2 siblings, 0 replies; 23+ messages in thread From: Jeffrey Carter @ 2004-10-13 1:23 UTC (permalink / raw) skidmarks wrote: > > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-12 18:44 ` skidmarks 2004-10-13 1:23 ` Jeffrey Carter @ 2004-10-13 8:07 ` Martin Krischik 2004-10-13 16:27 ` Jean-Pierre Rosen 2 siblings, 0 replies; 23+ messages in thread From: Martin Krischik @ 2004-10-13 8:07 UTC (permalink / raw) skidmarks wrote: > Stephen Leake <stephen_leake@acm.org> wrote in message > news:<mailman.269.1097458704.390.comp.lang.ada@ada-france.org>... >> aschwarz@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 Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-12 18:44 ` skidmarks 2004-10-13 1:23 ` Jeffrey Carter 2004-10-13 8:07 ` Martin Krischik @ 2004-10-13 16:27 ` Jean-Pierre Rosen 2 siblings, 0 replies; 23+ messages in thread From: Jean-Pierre Rosen @ 2004-10-13 16:27 UTC (permalink / raw) skidmarks a écrit : > 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 (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-10 19:50 Ada Pointer Size Problem skidmarks 2004-10-11 1:38 ` Stephen Leake @ 2004-10-11 5:18 ` Jeffrey Carter 2004-10-21 1:16 ` Dave Thompson 2004-10-11 8:45 ` Martin Krischik 2 siblings, 1 reply; 23+ messages in thread From: Jeffrey Carter @ 2004-10-11 5:18 UTC (permalink / raw) skidmarks wrote: > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-11 5:18 ` Jeffrey Carter @ 2004-10-21 1:16 ` Dave Thompson 2004-10-21 1:56 ` Jeffrey Carter 0 siblings, 1 reply; 23+ messages in thread From: Dave Thompson @ 2004-10-21 1:16 UTC (permalink / raw) On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <spam@spam.com> 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-21 1:16 ` Dave Thompson @ 2004-10-21 1:56 ` Jeffrey Carter 2004-10-21 9:54 ` Martin Krischik ` (3 more replies) 0 siblings, 4 replies; 23+ messages in thread From: Jeffrey Carter @ 2004-10-21 1:56 UTC (permalink / raw) Dave Thompson wrote: > On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <spam@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-21 1:56 ` Jeffrey Carter @ 2004-10-21 9:54 ` Martin Krischik 2004-10-22 1:09 ` Jeffrey Carter 2004-10-22 5:41 ` Simon Wright ` (2 subsequent siblings) 3 siblings, 1 reply; 23+ messages in thread From: Martin Krischik @ 2004-10-21 9:54 UTC (permalink / raw) Jeffrey Carter wrote: > Dave Thompson wrote: > >> On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <spam@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 Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-21 9:54 ` Martin Krischik @ 2004-10-22 1:09 ` Jeffrey Carter 2004-10-22 7:48 ` Martin Krischik 0 siblings, 1 reply; 23+ messages in thread From: Jeffrey Carter @ 2004-10-22 1:09 UTC (permalink / raw) 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. 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-22 1:09 ` Jeffrey Carter @ 2004-10-22 7:48 ` Martin Krischik 2004-10-22 9:41 ` Adrien Plisson 2004-10-23 1:35 ` Jeffrey Carter 0 siblings, 2 replies; 23+ messages in thread From: Martin Krischik @ 2004-10-22 7:48 UTC (permalink / raw) Jeffrey Carter wrote: > 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. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-22 7:48 ` Martin Krischik @ 2004-10-22 9:41 ` Adrien Plisson 2004-10-22 16:50 ` Warren W. Gay VE3WWG 2004-10-24 16:05 ` Martin Krischik 2004-10-23 1:35 ` Jeffrey Carter 1 sibling, 2 replies; 23+ messages in thread From: Adrien Plisson @ 2004-10-22 9:41 UTC (permalink / raw) 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. 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-22 9:41 ` Adrien Plisson @ 2004-10-22 16:50 ` Warren W. Gay VE3WWG 2004-10-24 16:05 ` Martin Krischik 1 sibling, 0 replies; 23+ messages in thread From: Warren W. Gay VE3WWG @ 2004-10-22 16:50 UTC (permalink / raw) Adrien Plisson wrote: > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-22 9:41 ` Adrien Plisson 2004-10-22 16:50 ` Warren W. Gay VE3WWG @ 2004-10-24 16:05 ` Martin Krischik 1 sibling, 0 replies; 23+ messages in thread From: Martin Krischik @ 2004-10-24 16:05 UTC (permalink / raw) Adrien Plisson wrote: > 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. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-22 7:48 ` Martin Krischik 2004-10-22 9:41 ` Adrien Plisson @ 2004-10-23 1:35 ` Jeffrey Carter 2004-10-24 15:52 ` Martin Krischik 1 sibling, 1 reply; 23+ messages in thread From: Jeffrey Carter @ 2004-10-23 1:35 UTC (permalink / raw) Martin Krischik wrote: > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-23 1:35 ` Jeffrey Carter @ 2004-10-24 15:52 ` Martin Krischik 0 siblings, 0 replies; 23+ messages in thread From: Martin Krischik @ 2004-10-24 15:52 UTC (permalink / raw) Jeffrey Carter wrote: > 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> With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-21 1:56 ` Jeffrey Carter 2004-10-21 9:54 ` Martin Krischik @ 2004-10-22 5:41 ` Simon Wright 2004-10-22 18:05 ` Mark Lorenzen 2004-11-01 8:14 ` Dave Thompson 3 siblings, 0 replies; 23+ messages in thread From: Simon Wright @ 2004-10-22 5:41 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> writes: > Dave Thompson wrote: > > > On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <spam@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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-21 1:56 ` Jeffrey Carter 2004-10-21 9:54 ` Martin Krischik 2004-10-22 5:41 ` Simon Wright @ 2004-10-22 18:05 ` Mark Lorenzen 2004-11-01 8:14 ` Dave Thompson 3 siblings, 0 replies; 23+ messages in thread From: Mark Lorenzen @ 2004-10-22 18:05 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> writes: > Dave Thompson wrote: > > > On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <spam@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-21 1:56 ` Jeffrey Carter ` (2 preceding siblings ...) 2004-10-22 18:05 ` Mark Lorenzen @ 2004-11-01 8:14 ` Dave Thompson 3 siblings, 0 replies; 23+ messages in thread From: Dave Thompson @ 2004-11-01 8:14 UTC (permalink / raw) On Thu, 21 Oct 2004 01:56:28 GMT, Jeffrey Carter <spam@spam.com> wrote: > Dave Thompson wrote: > > > On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <spam@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem 2004-10-10 19:50 Ada Pointer Size Problem skidmarks 2004-10-11 1:38 ` Stephen Leake 2004-10-11 5:18 ` Jeffrey Carter @ 2004-10-11 8:45 ` Martin Krischik [not found] ` <1c2f5137.0410130505.57e03c@posting.google.com> 2 siblings, 1 reply; 23+ messages in thread From: Martin Krischik @ 2004-10-11 8:45 UTC (permalink / raw) skidmarks wrote: > 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://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <1c2f5137.0410130505.57e03c@posting.google.com>]
* Re: Ada Pointer Size Problem [not found] ` <1c2f5137.0410130505.57e03c@posting.google.com> @ 2004-10-13 13:37 ` Dmitry A. Kazakov 2004-10-14 3:46 ` Steve 1 sibling, 0 replies; 23+ messages in thread From: Dmitry A. Kazakov @ 2004-10-13 13:37 UTC (permalink / raw) On 13 Oct 2004 06:05:59 -0700, Hans Van den Eynden wrote: > Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1404015.dag8674995@linux1.krischik.com>... >> skidmarks wrote: >> >>> 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 > >> 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 ?? 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Pointer Size Problem [not found] ` <1c2f5137.0410130505.57e03c@posting.google.com> 2004-10-13 13:37 ` Dmitry A. Kazakov @ 2004-10-14 3:46 ` Steve 1 sibling, 0 replies; 23+ messages in thread From: Steve @ 2004-10-14 3:46 UTC (permalink / raw) The package "System.Address_To_Access_Conversions" is what you're looking for. http://www.adaic.org/standards/95lrm/html/RM-13-7-2.html Steve (The Duck) "Hans Van den Eynden" <onsbomma@hotmail.com> wrote in message news:1c2f5137.0410130505.57e03c@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 ?? > I also can't anything about System.Address in the Ada95RM, a leftover > from Ada83? ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2004-11-01 8:14 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-10-10 19:50 Ada Pointer Size Problem skidmarks 2004-10-11 1:38 ` Stephen Leake 2004-10-12 18:44 ` skidmarks 2004-10-13 1:23 ` Jeffrey Carter 2004-10-13 8:07 ` Martin Krischik 2004-10-13 16:27 ` Jean-Pierre Rosen 2004-10-11 5:18 ` Jeffrey Carter 2004-10-21 1:16 ` Dave Thompson 2004-10-21 1:56 ` Jeffrey Carter 2004-10-21 9:54 ` Martin Krischik 2004-10-22 1:09 ` Jeffrey Carter 2004-10-22 7:48 ` Martin Krischik 2004-10-22 9:41 ` Adrien Plisson 2004-10-22 16:50 ` Warren W. Gay VE3WWG 2004-10-24 16:05 ` Martin Krischik 2004-10-23 1:35 ` Jeffrey Carter 2004-10-24 15:52 ` Martin Krischik 2004-10-22 5:41 ` Simon Wright 2004-10-22 18:05 ` Mark Lorenzen 2004-11-01 8:14 ` Dave Thompson 2004-10-11 8:45 ` Martin Krischik [not found] ` <1c2f5137.0410130505.57e03c@posting.google.com> 2004-10-13 13:37 ` Dmitry A. Kazakov 2004-10-14 3:46 ` Steve
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox