* To collection (GNAT bug) @ 2006-09-30 19:46 Dmitry A. Kazakov 2006-10-01 1:21 ` Jeffrey R. Carter 0 siblings, 1 reply; 19+ messages in thread From: Dmitry A. Kazakov @ 2006-09-30 19:46 UTC (permalink / raw) The following does not work in GCC 4.1.1 (20060525), as well as in 3.15p ----------------- with Ada.Unchecked_Conversion; with Ada.Text_IO; use Ada.Text_IO; with System; use System; procedure Test_String_Ptr is type Ptr is access String; function To_Addr is new Ada.Unchecked_Conversion (Ptr, Address); function To_Ptr is new Ada.Unchecked_Conversion (Address, Ptr); X : Ptr; Y : Ptr; Addr : Address; begin X := new String'("A"); Addr := To_Addr (X); Y := To_Ptr (Addr); Put_Line (Y.all); Y := To_Ptr (Addr); Put_Line (Y.all); Y := To_Ptr (Addr); Put_Line (Y.all); Put_Line ("It must have been three lines ""A"""); end Test_String_Ptr; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-09-30 19:46 To collection (GNAT bug) Dmitry A. Kazakov @ 2006-10-01 1:21 ` Jeffrey R. Carter 2006-10-01 8:00 ` Dmitry A. Kazakov 0 siblings, 1 reply; 19+ messages in thread From: Jeffrey R. Carter @ 2006-10-01 1:21 UTC (permalink / raw) Dmitry A. Kazakov wrote: > The following does not work in GCC 4.1.1 (20060525), as well as in 3.15p Why should it? There's no guarantee that unchecked conversion between access values and System.Address will give meaningful results. Use System.Address_To_Access_Conversions. -- Jeff Carter "Sir Lancelot saves Sir Gallahad from almost certain temptation." Monty Python & the Holy Grail 69 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-01 1:21 ` Jeffrey R. Carter @ 2006-10-01 8:00 ` Dmitry A. Kazakov 2006-10-01 19:23 ` Jeffrey R. Carter 0 siblings, 1 reply; 19+ messages in thread From: Dmitry A. Kazakov @ 2006-10-01 8:00 UTC (permalink / raw) On Sun, 01 Oct 2006 01:21:22 GMT, Jeffrey R. Carter wrote: > Dmitry A. Kazakov wrote: >> The following does not work in GCC 4.1.1 (20060525), as well as in 3.15p > > Why should it? There's no guarantee that unchecked conversion between > access values and System.Address will give meaningful results. See ARM 13.9 (17), which requires reversibility of Unchecked_Conversion. That is clearly violated in the example given. Though it is legal not to provide address to access type conversion through Unchecked_Conversion, it is still illegal to provide it wrong. > Use System.Address_To_Access_Conversions. Address_To_Access_Conversions serves a different purpose. It declares a new access type, moreover it is a general access type. BTW, when Address_To_Access_Conversions is composed with an access to access type conversion, the problem persists (it is a bug after all (:-)) Replace To_Ptr and To_Addr with: package Clutter is new Address_To_Access_Conversions (String); function To_Addr (X : Ptr) return Address is begin return Clutter.To_Address (X.all'Unchecked_Access); end To_Addr; function To_Ptr (X : Address) return Ptr is function Cast is new Ada.Unchecked_Conversion (Clutter.Object_Pointer, Ptr); begin return Cast (Clutter.To_Pointer (X)); end To_Ptr; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-01 8:00 ` Dmitry A. Kazakov @ 2006-10-01 19:23 ` Jeffrey R. Carter 2006-10-01 22:33 ` Frank J. Lhota 2006-10-02 8:23 ` Dmitry A. Kazakov 0 siblings, 2 replies; 19+ messages in thread From: Jeffrey R. Carter @ 2006-10-01 19:23 UTC (permalink / raw) Dmitry A. Kazakov wrote: > > See ARM 13.9 (17), which requires reversibility of Unchecked_Conversion. > That is clearly violated in the example given. Though it is legal not to > provide address to access type conversion through Unchecked_Conversion, it > is still illegal to provide it wrong. It doesn't require it; it merely advises it, and then only "where this clause defines the result". "This clause defines the result" only when "The representation of S is a representation of an object of the target subtype". That is not necessarily true in your case. So lack of reversibility is not an error, even for a compiler that adheres to this advice. > Address_To_Access_Conversions serves a different purpose. It declares a new > access type, moreover it is a general access type. That it defines its own access type is a design error, I agree, but not a serious one. Rather than define your own access type, you use the one defined by the instance of the package. -- Jeff Carter "Monsieur Arthur King, who has the brain of a duck, you know." Monty Python & the Holy Grail 09 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-01 19:23 ` Jeffrey R. Carter @ 2006-10-01 22:33 ` Frank J. Lhota 2006-10-02 3:08 ` Jeffrey R. Carter 2006-10-02 8:23 ` Dmitry A. Kazakov 1 sibling, 1 reply; 19+ messages in thread From: Frank J. Lhota @ 2006-10-01 22:33 UTC (permalink / raw) "Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message news:OAUTg.1003007$084.622552@attbi_s22... > Dmitry A. Kazakov wrote: >> Address_To_Access_Conversions serves a different purpose. It declares a >> new >> access type, moreover it is a general access type. > > That it defines its own access type is a design error, I agree, but not a > serious one. Rather than define your own access type, you use the one > defined by the instance of the package. The reason why Address_To_Access_Conversions declares its own access type is to make sure that the access values used in these conversions are not "fat pointers". In other words, this design was chosen precisely to avoid the sort of problems exhibited in Test_String_Ptr. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-01 22:33 ` Frank J. Lhota @ 2006-10-02 3:08 ` Jeffrey R. Carter 2006-10-02 13:02 ` Frank J. Lhota 0 siblings, 1 reply; 19+ messages in thread From: Jeffrey R. Carter @ 2006-10-02 3:08 UTC (permalink / raw) Frank J. Lhota wrote: > > The reason why Address_To_Access_Conversions declares its own access type is > to make sure that the access values used in these conversions are not "fat > pointers". In other words, this design was chosen precisely to avoid the > sort of problems exhibited in Test_String_Ptr. Since you can instantiate System.Address_To_Access_Conversions with type String, I don't see how its access type can be any different than one you declare yourself. -- Jeff Carter "Monsieur Arthur King, who has the brain of a duck, you know." Monty Python & the Holy Grail 09 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-02 3:08 ` Jeffrey R. Carter @ 2006-10-02 13:02 ` Frank J. Lhota 2006-10-02 19:50 ` Jeffrey R. Carter 0 siblings, 1 reply; 19+ messages in thread From: Frank J. Lhota @ 2006-10-02 13:02 UTC (permalink / raw) Jeffrey R. Carter wrote: > Frank J. Lhota wrote: > > Since you can instantiate System.Address_To_Access_Conversions with type > String, I don't see how its access type can be any different than one > you declare yourself. > It can have pragmas and representation clauses needed to make sure that the To_Pointer and To_Address functions are meaningful. For example, the GNAT version of this package includes the representation clause for Object_Pointer'Size use Standard'Address_Size; which precludes implementing Object_Pointer as a "fat" pointer. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-02 13:02 ` Frank J. Lhota @ 2006-10-02 19:50 ` Jeffrey R. Carter 0 siblings, 0 replies; 19+ messages in thread From: Jeffrey R. Carter @ 2006-10-02 19:50 UTC (permalink / raw) Frank J. Lhota wrote: > > It can have pragmas and representation clauses needed to make sure that > the To_Pointer and To_Address functions are meaningful. For example, the > GNAT version of this package includes the representation clause > > for Object_Pointer'Size use Standard'Address_Size; > > which precludes implementing Object_Pointer as a "fat" pointer. Ah, yes. I'd forgotten the "additional implementation-defined declarations to package System and its children" permission. -- Jeff Carter "It's all right, Taggart. Just a man and a horse being hung out there." Blazing Saddles 34 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-01 19:23 ` Jeffrey R. Carter 2006-10-01 22:33 ` Frank J. Lhota @ 2006-10-02 8:23 ` Dmitry A. Kazakov 2006-10-02 13:06 ` Frank J. Lhota 2006-10-02 19:45 ` Jeffrey R. Carter 1 sibling, 2 replies; 19+ messages in thread From: Dmitry A. Kazakov @ 2006-10-02 8:23 UTC (permalink / raw) On Sun, 01 Oct 2006 19:23:26 GMT, Jeffrey R. Carter wrote: > Dmitry A. Kazakov wrote: >> >> See ARM 13.9 (17), which requires reversibility of Unchecked_Conversion. >> That is clearly violated in the example given. Though it is legal not to >> provide address to access type conversion through Unchecked_Conversion, it >> is still illegal to provide it wrong. > > It doesn't require it; it merely advises it, and then only "where this > clause defines the result". "This clause defines the result" only when > "The representation of S is a representation of an object of the target > subtype". That is not necessarily true in your case. So lack of > reversibility is not an error, even for a compiler that adheres to this > advice. OK, it can be classified as implementation-defined, because the compiler designer can always claim that Address representation is not the pointer's one. Who could rebut him? However, I don't think that it was really the intended behavior in this case. [ If access String is a fat pointer, then Unchecked_Conversion should not be allowed at all. Otherwise it must honor the String's dope. ] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-02 8:23 ` Dmitry A. Kazakov @ 2006-10-02 13:06 ` Frank J. Lhota 2006-10-02 13:43 ` Dmitry A. Kazakov 2006-10-02 19:45 ` Jeffrey R. Carter 1 sibling, 1 reply; 19+ messages in thread From: Frank J. Lhota @ 2006-10-02 13:06 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Sun, 01 Oct 2006 19:23:26 GMT, Jeffrey R. Carter wrote: > However, I don't think that it was really the intended behavior in this > case. [ If access String is a fat pointer, then Unchecked_Conversion should > not be allowed at all. Otherwise it must honor the String's dope. ] I would agree that an unchecked conversion between an address and a fat pointer (or any two types of different sizes, for that matter) should at least trigger a warning. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-02 13:06 ` Frank J. Lhota @ 2006-10-02 13:43 ` Dmitry A. Kazakov 2006-10-04 17:18 ` Adam Beneschan 0 siblings, 1 reply; 19+ messages in thread From: Dmitry A. Kazakov @ 2006-10-02 13:43 UTC (permalink / raw) On Mon, 02 Oct 2006 09:06:42 -0400, Frank J. Lhota wrote: > Dmitry A. Kazakov wrote: >> On Sun, 01 Oct 2006 19:23:26 GMT, Jeffrey R. Carter wrote: >> However, I don't think that it was really the intended behavior in this >> case. [ If access String is a fat pointer, then Unchecked_Conversion should >> not be allowed at all. Otherwise it must honor the String's dope. ] > > I would agree that an unchecked conversion between an address and a fat > pointer (or any two types of different sizes, for that matter) should at > least trigger a warning. Well, actually, it gives a warning, that sizes are different. I think that a warning is not enough. But there is a nasty issue with generics. Let Unchecked_Conversion were instantiated in a generic body, then the compiler should either forbid or support conversions of all access types - it never knows if the actual access type were fat. A cleaner way were, IMO, to pass the conversion as a formal parameter and allow ad-hoc instantiations as subprogram defaults. Something like: generic type T is ...; type Ptr is access T; -- It could be fat with function To_Ptr (A : Address) return Ptr is new Ada.Unchecked_Conversion (T, Ptr); package Separately_Compilable_Generic_Body is Then the compiler could safely compile the body and complain upon an instantiation. But it still does not help when the access type is declared within the generic body. Then the compiler should forget about fat pointers. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-02 13:43 ` Dmitry A. Kazakov @ 2006-10-04 17:18 ` Adam Beneschan 2006-10-04 18:51 ` Dmitry A. Kazakov 0 siblings, 1 reply; 19+ messages in thread From: Adam Beneschan @ 2006-10-04 17:18 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Mon, 02 Oct 2006 09:06:42 -0400, Frank J. Lhota wrote: > > > Dmitry A. Kazakov wrote: > >> On Sun, 01 Oct 2006 19:23:26 GMT, Jeffrey R. Carter wrote: > >> However, I don't think that it was really the intended behavior in this > >> case. [ If access String is a fat pointer, then Unchecked_Conversion should > >> not be allowed at all. Otherwise it must honor the String's dope. ] > > > > I would agree that an unchecked conversion between an address and a fat > > pointer (or any two types of different sizes, for that matter) should at > > least trigger a warning. > > Well, actually, it gives a warning, that sizes are different. Ummm, wait a minute. If the sizes are different, why did you think that the Unchecked_Conversion would be reversible? I tried your example on GNAT (Linux/x86), and it told me that X'Size=64 and Addr'Size=32. When you convert the 64-bit type to the 32-bit type, of course you will lose some information that you won't recover when you get it back. It's mathematically impossible for this to be reversible. -- Adam ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-04 17:18 ` Adam Beneschan @ 2006-10-04 18:51 ` Dmitry A. Kazakov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry A. Kazakov @ 2006-10-04 18:51 UTC (permalink / raw) On 4 Oct 2006 10:18:47 -0700, Adam Beneschan wrote: > Dmitry A. Kazakov wrote: >> On Mon, 02 Oct 2006 09:06:42 -0400, Frank J. Lhota wrote: >> >>> Dmitry A. Kazakov wrote: >>>> On Sun, 01 Oct 2006 19:23:26 GMT, Jeffrey R. Carter wrote: >>>> However, I don't think that it was really the intended behavior in this >>>> case. [ If access String is a fat pointer, then Unchecked_Conversion should >>>> not be allowed at all. Otherwise it must honor the String's dope. ] >>> >>> I would agree that an unchecked conversion between an address and a fat >>> pointer (or any two types of different sizes, for that matter) should at >>> least trigger a warning. >> >> Well, actually, it gives a warning, that sizes are different. > > Ummm, wait a minute. If the sizes are different, why did you think > that the Unchecked_Conversion would be reversible? I tried your > example on GNAT (Linux/x86), and it told me that X'Size=64 and > Addr'Size=32. When you convert the 64-bit type to the 32-bit type, of > course you will lose some information that you won't recover when you > get it back. It's mathematically impossible for this to be reversible. It is quite possible. The dope is obtained by dereferencing the address being converted. (I assume GNAT stores the dope in that fat pointer.) If Unchecked_Conversion did not restore a correct pointer under any thinkable circumstances, then its instantiation should be illegal. After all, GNAT is not required to provide it when sizes are different. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-02 8:23 ` Dmitry A. Kazakov 2006-10-02 13:06 ` Frank J. Lhota @ 2006-10-02 19:45 ` Jeffrey R. Carter 2006-10-03 8:36 ` Dmitry A. Kazakov 1 sibling, 1 reply; 19+ messages in thread From: Jeffrey R. Carter @ 2006-10-02 19:45 UTC (permalink / raw) Dmitry A. Kazakov wrote: > > OK, it can be classified as implementation-defined, because the compiler > designer can always claim that Address representation is not the pointer's > one. Who could rebut him? Since you say elsewhere that it gave you a warning about the sizes being different, it would appear that this is in fact the case. > However, I don't think that it was really the intended behavior in this > case. [ If access String is a fat pointer, then Unchecked_Conversion should > not be allowed at all. Otherwise it must honor the String's dope. ] This is unchecked programming, where the programmer is telling the compiler, "I know what I'm doing, even if it looks like I don't." And, of course, even when he doesn't. Perhaps you know that the 1st 4 bytes of the access value are an address. So the compiler can warn you, but it shouldn't prevent you. -- Jeff Carter "It's all right, Taggart. Just a man and a horse being hung out there." Blazing Saddles 34 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-02 19:45 ` Jeffrey R. Carter @ 2006-10-03 8:36 ` Dmitry A. Kazakov 2006-10-03 19:10 ` Jeffrey R. Carter 0 siblings, 1 reply; 19+ messages in thread From: Dmitry A. Kazakov @ 2006-10-03 8:36 UTC (permalink / raw) On Mon, 02 Oct 2006 19:45:53 GMT, Jeffrey R. Carter wrote: > Dmitry A. Kazakov wrote: >> >> OK, it can be classified as implementation-defined, because the compiler >> designer can always claim that Address representation is not the pointer's >> one. Who could rebut him? > > Since you say elsewhere that it gave you a warning about the sizes being > different, it would appear that this is in fact the case. Even if the sizes were same, and even if the bit patterns were exactly same, one could always claim that representations are different. >> However, I don't think that it was really the intended behavior in this >> case. [ If access String is a fat pointer, then Unchecked_Conversion should >> not be allowed at all. Otherwise it must honor the String's dope. ] > > This is unchecked programming, where the programmer is telling the > compiler, "I know what I'm doing, even if it looks like I don't." No. These aren't equivalent. In many cases the programmer does not know what he is doing on the level of bits and bytes. Otherwise he probably wouldn't instantiate Unchecked_Conversion, but wrote a conversion of his own. He only knows the semantics of an object and asks the compiler to convert the types according to this semantics. It is a deal - the programmer knows the semantics, the compiler does the representation. > And, > of course, even when he doesn't. Perhaps you know that the 1st 4 bytes > of the access value are an address. So the compiler can warn you, but it > shouldn't prevent you. Hmm, warning makes sense when the suspicious construct might turn either wrong or correct depending on the context, which were difficult or impossible to check. A conversion that creates a garbage dope is always wrong. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-03 8:36 ` Dmitry A. Kazakov @ 2006-10-03 19:10 ` Jeffrey R. Carter 2006-10-04 8:01 ` Dmitry A. Kazakov 0 siblings, 1 reply; 19+ messages in thread From: Jeffrey R. Carter @ 2006-10-03 19:10 UTC (permalink / raw) Dmitry A. Kazakov wrote: > > No. These aren't equivalent. In many cases the programmer does not know > what he is doing on the level of bits and bytes. Otherwise he probably > wouldn't instantiate Unchecked_Conversion, but wrote a conversion of his > own. He only knows the semantics of an object and asks the compiler to > convert the types according to this semantics. It is a deal - the > programmer knows the semantics, the compiler does the representation. I think you misunderstand the meaning of unchecked. 'Unchecked_Access tells the compiler that this access value will not violate the accessibility rules, even though the compiler thinks it will. Unchecked_Deallocation tells the compiler that there are no other references to this designated object, even if there are. And Unchecked_Conversion means to interpret the bit pattern starting with the bits of this value as being of that type, whether it makes sense or not. It does not involve a change of representation. In terms of object code, Unchecked_Deallocation does nothing; it merely provides a way around the restrictions of the language. -- Jeff Carter "You empty-headed animal-food-trough wiper." Monty Python & the Holy Grail 04 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-03 19:10 ` Jeffrey R. Carter @ 2006-10-04 8:01 ` Dmitry A. Kazakov 2006-10-04 9:27 ` Georg Bauhaus 0 siblings, 1 reply; 19+ messages in thread From: Dmitry A. Kazakov @ 2006-10-04 8:01 UTC (permalink / raw) On Tue, 03 Oct 2006 19:10:57 GMT, Jeffrey R. Carter wrote: > Dmitry A. Kazakov wrote: >> >> No. These aren't equivalent. In many cases the programmer does not know >> what he is doing on the level of bits and bytes. Otherwise he probably >> wouldn't instantiate Unchecked_Conversion, but wrote a conversion of his >> own. He only knows the semantics of an object and asks the compiler to >> convert the types according to this semantics. It is a deal - the >> programmer knows the semantics, the compiler does the representation. > > I think you misunderstand the meaning of unchecked. 'Unchecked_Access > tells the compiler that this access value will not violate the > accessibility rules, even though the compiler thinks it will. > Unchecked_Deallocation tells the compiler that there are no other > references to this designated object, even if there are. And > Unchecked_Conversion means to interpret the bit pattern starting with > the bits of this value as being of that type, whether it makes sense or > not. It does not involve a change of representation. In terms of object > code, Unchecked_Deallocation does nothing; it merely provides a way > around the restrictions of the language. IFF "The representation of S is a representation of an object of the target subtype" [13.9(10)] BUT "Otherwise, the effect is implementation defined; in particular, the result can be abnormal" [13.9(11)] For example, when an array indexed by a 8-bit modular type is converted to an array indexed by 32-bit integer, then surely the dope will have a different bit pattern, and size. 13.9(14) even suggests that the dope size does not count as "size." ARM does not prohibit reasonable implementations of Unchecked_Conversion. OK, it does not enforce them either. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-04 8:01 ` Dmitry A. Kazakov @ 2006-10-04 9:27 ` Georg Bauhaus 2006-10-04 12:10 ` Dmitry A. Kazakov 0 siblings, 1 reply; 19+ messages in thread From: Georg Bauhaus @ 2006-10-04 9:27 UTC (permalink / raw) On Wed, 2006-10-04 at 10:01 +0200, Dmitry A. Kazakov wrote: > ARM does not prohibit reasonable implementations of Unchecked_Conversion. > OK, it does not enforce them either. I guess that the makers of GNAT might argue that their compiler handles internal representations of objects in a quite reasonable way, that is, reasonable as considered by their Ada customers and by a compiler back-end writer. If you would like to have user level internal data structure representation interfaces for arrays, pointers, etc., how do you envision a suitably modified Ada compiler to guarantee separate compilation, optimization, and LRM-correct behavior in the presence of user-defined internal representations? Georg ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: To collection (GNAT bug) 2006-10-04 9:27 ` Georg Bauhaus @ 2006-10-04 12:10 ` Dmitry A. Kazakov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry A. Kazakov @ 2006-10-04 12:10 UTC (permalink / raw) On Wed, 04 Oct 2006 11:27:15 +0200, Georg Bauhaus wrote: > If you would like to have user level internal data structure > representation interfaces for arrays, pointers, etc., No, I don't like to care about them. This is exactly why the language/compiler provided conversions must be reasonable, or else illegal. Ada is not C. > how do you envision a suitably modified Ada compiler to guarantee > separate compilation, optimization, and LRM-correct > behavior in the presence of user-defined internal representations? You should ask this question yourself. In particular, consider the code I sent once: package Legal is new Address_To_Access_Conversions (String); function To_Addr (X : Ptr) return Address is begin return Legal.To_Address (X.all'Unchecked_Access); end To_Addr; -- This is safe function To_Ptr (X : Address) return Ptr is function Cast is new Ada.Unchecked_Conversion (Legal.Object_Pointer, Ptr); begin return Cast (Legal.To_Pointer (X)); end To_Ptr; What is user-defined in To_Ptr (To_Addr (X))? ---------------------- Clearly a lack of safe general to pool specific conversion of access types is a language design fault. So? Should the compiler vendors make it even worse, by making Unchecked_Conversion return rubbish when the programmer resort to it? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2006-10-04 18:51 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-09-30 19:46 To collection (GNAT bug) Dmitry A. Kazakov 2006-10-01 1:21 ` Jeffrey R. Carter 2006-10-01 8:00 ` Dmitry A. Kazakov 2006-10-01 19:23 ` Jeffrey R. Carter 2006-10-01 22:33 ` Frank J. Lhota 2006-10-02 3:08 ` Jeffrey R. Carter 2006-10-02 13:02 ` Frank J. Lhota 2006-10-02 19:50 ` Jeffrey R. Carter 2006-10-02 8:23 ` Dmitry A. Kazakov 2006-10-02 13:06 ` Frank J. Lhota 2006-10-02 13:43 ` Dmitry A. Kazakov 2006-10-04 17:18 ` Adam Beneschan 2006-10-04 18:51 ` Dmitry A. Kazakov 2006-10-02 19:45 ` Jeffrey R. Carter 2006-10-03 8:36 ` Dmitry A. Kazakov 2006-10-03 19:10 ` Jeffrey R. Carter 2006-10-04 8:01 ` Dmitry A. Kazakov 2006-10-04 9:27 ` Georg Bauhaus 2006-10-04 12:10 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox