comp.lang.ada
 help / color / mirror / Atom feed
* Gnat's Handling of Record with Address Clause
@ 2013-09-26 14:23 Eryndlia Mavourneen
  2013-09-26 14:48 ` Adam Beneschan
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Eryndlia Mavourneen @ 2013-09-26 14:23 UTC (permalink / raw)


The following heavily edited code fragment is disallowed by Gnat:

   package body Callback_Pkg is
      Max_Message_Size : constant Natural := 16 * 512;
      subtype My_Message_L_T is Natural range 1 .. Natural (Max_Message_Size);

      type My_Buffer_T (My_Message_L : My_Message_L_T) is
         record
            My_Message_S : String (1 .. My_Message_L);
         end record;

      Local_Buffer_Addr : An_Addr_Type;

      procedure Callback_Proc (Message      : An_Addr_Type;
                               Message_Size : A_Size_Type) is
      begin
         Local_Buffer_Addr := Message;

         Declare_Buffer:
         declare
            Local_Buffer : My_Buffer_T with Address => Local_Buffer_Addr;
         begin
            Put_Line (...);
         end Declare_Buffer;
      end Callback_Proc;
   end Callback_Pkg;

NOTE that type My_Buffer_T, subtype My_Message_L_T, and constant Max_Message_Size are all defined in an external package at top level.  I have placed them here for easy reference.

Gnat tells me:

1) (for Local_Buffer)
   unconstrained subtype not allowed (need initialization)

   provide initial value or explicit discriminant values

   or give default discriminant values for type "My_Buffer_T"

2) (also for Local_Buffer)
   invalid address clause for initialized object "Local_Buffer"

   reference to variable "Local_Buffer_Addr" not allowed (RM 13.1(22))

I can understand (1), and I can initialize the record's discriminant, doing away with this message; however, I do not understand that (2) says the record is initialized, unless it is some kind of default initialization.

RM 13.1(22) says: "An implementation need not support the specification for a representation aspect that contains nonstatic expressions, unless each nonstatic expression is a name that statically denotes a constant declared before the entity."

The overall effect of all this appears to be that Gnat is allowed to disallow a dynamically-determined address for an object.  If this is what is happening here (not a bug in Gnat), then it would seem that any kind of OS work, looping through a kernel linked list, for instance, would not be possible.

A further NOTE:  (1) says truthfully that the immediate definition of Local_Buffer is not initialized; however, that assumption ignores the address clause.  With the address clause, Local_Buffer *is* initialized at the specified address.  Perhaps Gnat's error should be changed to a warning in this case.

Any help here on these issues?

-- Eryndlia (KK1T)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Gnat's Handling of Record with Address Clause
  2013-09-26 14:23 Gnat's Handling of Record with Address Clause Eryndlia Mavourneen
@ 2013-09-26 14:48 ` Adam Beneschan
  2013-09-26 15:05   ` Eryndlia Mavourneen
  2013-09-26 15:09 ` Adam Beneschan
  2013-09-26 20:00 ` Shark8
  2 siblings, 1 reply; 8+ messages in thread
From: Adam Beneschan @ 2013-09-26 14:48 UTC (permalink / raw)


On Thursday, September 26, 2013 7:23:36 AM UTC-7, Eryndlia Mavourneen wrote:

I haven't looked over the whole post yet, but just looking at this part:

> RM 13.1(22) says: "An implementation need not support the specification for a representation aspect that contains nonstatic expressions, unless each nonstatic expression is a name that statically denotes a constant declared before the entity."
> 
> The overall effect of all this appears to be that Gnat is allowed to disallow a dynamically-determined address for an object.  If this is what is happening here (not a bug in Gnat), then it would seem that any kind of OS work, looping through a kernel linked list, for instance, would not be possible.

it seems that you could still use System.Address_To_Access_Conversions to achieve what you need.  (RM 13.7.2)

                              -- Adam


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Gnat's Handling of Record with Address Clause
  2013-09-26 14:48 ` Adam Beneschan
@ 2013-09-26 15:05   ` Eryndlia Mavourneen
  2013-09-26 15:21     ` Adam Beneschan
  0 siblings, 1 reply; 8+ messages in thread
From: Eryndlia Mavourneen @ 2013-09-26 15:05 UTC (permalink / raw)


On Thursday, September 26, 2013 9:48:23 AM UTC-5, Adam Beneschan wrote:
> On Thursday, September 26, 2013 7:23:36 AM UTC-7, Eryndlia Mavourneen wrote:
> 
> I haven't looked over the whole post yet, but just looking at this part:
> 
> > RM 13.1(22) says: "An implementation need not support the specification for a representation aspect that contains nonstatic expressions, unless each nonstatic expression is a name that statically denotes a constant declared before the entity."
> 
> > The overall effect of all this appears to be that Gnat is allowed to disallow a dynamically-determined address for an object.  If this is what is happening here (not a bug in Gnat), then it would seem that any kind of OS work, looping through a kernel linked list, for instance, would not be possible.
> 
> it seems that you could still use System.Address_To_Access_Conversions to achieve what you need.  (RM 13.7.2)
> 
>                               -- Adam

Thank you for the idea, Adam.  This sounds like an approach; I will try it.

Since the "Message" parameter is an address, I assume that you mean declaring an access type for My_Buffer_T, then doing the address -> access conversion for an access variable on that type.  

A lot of work to get around this Gnat issue.  I wonder why Adacore doesn't just allow you to do this in the first place.  The use of the Address clause should be enough of a flag of a potential problem.  -or-  Is this handling of a dynamic address really that difficult to implement?

-- Eryndlia (KK1T)


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Gnat's Handling of Record with Address Clause
  2013-09-26 14:23 Gnat's Handling of Record with Address Clause Eryndlia Mavourneen
  2013-09-26 14:48 ` Adam Beneschan
@ 2013-09-26 15:09 ` Adam Beneschan
  2013-09-26 15:46   ` Eryndlia Mavourneen
  2013-09-26 20:00 ` Shark8
  2 siblings, 1 reply; 8+ messages in thread
From: Adam Beneschan @ 2013-09-26 15:09 UTC (permalink / raw)


On Thursday, September 26, 2013 7:23:36 AM UTC-7, Eryndlia Mavourneen wrote:

> 2) (also for Local_Buffer)
> 
>    invalid address clause for initialized object "Local_Buffer"
>    reference to variable "Local_Buffer_Addr" not allowed (RM 13.1(22))
> 
> I can understand (1), and I can initialize the record's discriminant, doing away with this message; however, I do not understand that (2) says the record is initialized, unless it is some kind of default initialization.

When two errors occur on the same line, you can't always trust all the messages.  As a compiler maintainer, my experience is that error recovery can be hard.  Either the compiler just gives up and pretends the erroneous line doesn't exist, which could lead to inappropriate error messages later on; or it tries to make some assumptions so that it can continue, but it's not always going to do that perfectly.  Plus, making sure that error messages are totally accurate in a case like this is probably one of the lower priorities of a compiler writer.

If you do add a discriminant constraint, then the compiler must generate code to initialize the discriminant, so in that case the object *is* an initialized object.

                               -- Adam

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Gnat's Handling of Record with Address Clause
  2013-09-26 15:05   ` Eryndlia Mavourneen
@ 2013-09-26 15:21     ` Adam Beneschan
  0 siblings, 0 replies; 8+ messages in thread
From: Adam Beneschan @ 2013-09-26 15:21 UTC (permalink / raw)


On Thursday, September 26, 2013 8:05:17 AM UTC-7, Eryndlia Mavourneen wrote:

> Since the "Message" parameter is an address, I assume that you mean declaring an access type for My_Buffer_T, then doing the address -> access conversion for an access variable on that type.  

Yes.

> A lot of work to get around this Gnat issue.  

I think using System.Access_To_Address_Conversions is the right way to do it, regardless of whose compiler you're using.  Using an Address aspect on a discriminant record type like this is going to be problematic, without a specific language feature to support it.  As you found out, the language doesn't let you declare objects of indefinite types without specifying the constraints, even if you have an Address aspect; but if you do specify the discriminant constraint, what do you put for the constraint, given that the correct value will be something that has to be read from memory?  So there are language design issues involved with using Address on a discriminant record; it's not really a GNAT issue.  Even on a non-discriminant record, there are potential problems with the Address aspect because record fields that have implicit initializers are still going to be initialized, unless there's also an Import aspect.  (See AARM 13.3(12.d/3).)  

So on balance, it's probably right in general to use System.Address_To_Access_Conversions instead of Address aspects.

                              -- Adam

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Gnat's Handling of Record with Address Clause
  2013-09-26 15:09 ` Adam Beneschan
@ 2013-09-26 15:46   ` Eryndlia Mavourneen
  0 siblings, 0 replies; 8+ messages in thread
From: Eryndlia Mavourneen @ 2013-09-26 15:46 UTC (permalink / raw)


Good insights:  Thank you!

-- Eryndlia (KK1T)


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Gnat's Handling of Record with Address Clause
  2013-09-26 14:23 Gnat's Handling of Record with Address Clause Eryndlia Mavourneen
  2013-09-26 14:48 ` Adam Beneschan
  2013-09-26 15:09 ` Adam Beneschan
@ 2013-09-26 20:00 ` Shark8
  2013-09-27 12:55   ` Eryndlia Mavourneen
  2 siblings, 1 reply; 8+ messages in thread
From: Shark8 @ 2013-09-26 20:00 UTC (permalink / raw)


On Thursday, September 26, 2013 8:23:36 AM UTC-6, Eryndlia Mavourneen wrote:
>             Local_Buffer : My_Buffer_T with Address => Local_Buffer_Addr;

Hm, I think you might be able to get around the one error with an Import [and perhaps Convention] aspect.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Gnat's Handling of Record with Address Clause
  2013-09-26 20:00 ` Shark8
@ 2013-09-27 12:55   ` Eryndlia Mavourneen
  0 siblings, 0 replies; 8+ messages in thread
From: Eryndlia Mavourneen @ 2013-09-27 12:55 UTC (permalink / raw)


On Thursday, September 26, 2013 3:00:30 PM UTC-5, Shark8 wrote:
> On Thursday, September 26, 2013 8:23:36 AM UTC-6, Eryndlia Mavourneen wrote:
> 
> >             Local_Buffer : My_Buffer_T with Address => Local_Buffer_Addr;
> 
> 
> 
> Hm, I think you might be able to get around the one error with an Import [and perhaps Convention] aspect.

Thanks, Shark8, but I already have it working using the (holds nose) alternate method of address-access conversion.  :-)

Mainly, I just needed a demo to show myself that it is possible to use a procedure access type that is defined in a separate package.  Gnat's failure to fully implement the dynamic "with Address" clause/pragma plus the rules on using access types really made the code more complicated than I believe is necessary.

-- Eryndlia (KK1T)


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-09-27 12:55 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-26 14:23 Gnat's Handling of Record with Address Clause Eryndlia Mavourneen
2013-09-26 14:48 ` Adam Beneschan
2013-09-26 15:05   ` Eryndlia Mavourneen
2013-09-26 15:21     ` Adam Beneschan
2013-09-26 15:09 ` Adam Beneschan
2013-09-26 15:46   ` Eryndlia Mavourneen
2013-09-26 20:00 ` Shark8
2013-09-27 12:55   ` Eryndlia Mavourneen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox