To collection (GNAT bug)

To collection (GNAT bug)

[Dmitry A. Kazakov]

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

Re: To collection (GNAT bug)

[Jeffrey R. Carter]

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

Re: To collection (GNAT bug)

[Dmitry A. Kazakov]

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

Re: To collection (GNAT bug)

[Jeffrey R. Carter]

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

Re: To collection (GNAT bug)

[Frank J. Lhota]

"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.

Re: To collection (GNAT bug)

[Jeffrey R. Carter]

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

Re: To collection (GNAT bug)

[Frank J. Lhota]

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.

Re: To collection (GNAT bug)

[Jeffrey R. Carter]

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

Re: To collection (GNAT bug)

[Dmitry A. Kazakov]

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

Re: To collection (GNAT bug)

[Frank J. Lhota]

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.

Re: To collection (GNAT bug)

[Dmitry A. Kazakov]

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

Re: To collection (GNAT bug)

[Adam Beneschan]

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

Re: To collection (GNAT bug)

[Dmitry A. Kazakov]

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

Re: To collection (GNAT bug)

[Jeffrey R. Carter]

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

Re: To collection (GNAT bug)

[Dmitry A. Kazakov]

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

Re: To collection (GNAT bug)

[Jeffrey R. Carter]

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

Re: To collection (GNAT bug)

[Dmitry A. Kazakov]

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

Re: To collection (GNAT bug)

[Georg Bauhaus]

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 

Re: To collection (GNAT bug)

[Dmitry A. Kazakov]

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