!standard B.1 10-02-13 AC95-00189/01 !class confirmation 10-02-13 !status received no action 10-02-13 !status received 10-01-14 !subject Import pragma on dynamically-sized array !summary !appendix From: Adam Beneschan Sent: Thursday, January 14, 2010 3:55 PM I'd like some expert opinions about what the Ada language says about this situation, if anything. Suppose a subprogram has a local object that is an array whose bounds are not known at compile time: procedure Proc1 (X : String) is type X_Bytes is array (X'Range) of Interfaces.Unsigned_8; XB : X_Bytes; begin ... end Proc1; Some implementations will implement this by moving the stack pointer to make room for XB. But that may not be appropriate for all execution environments, so there could be implementations that allocate the data for XB in some other area of memory, and then XB is maintained (on the stack or in a register) as a pointer to that memory. Let's say this latter implementation is being used. Now someone writes this: procedure Proc2 (X : String) is type X_Bytes is array (X'Range) of Interfaces.Unsigned_8; XB : X_Bytes; pragma Import (Ada, XB, "external_symbol"); begin ... end Proc2; Keeping in mind that the convention of XB is Ada (not C or anything other language), which of the following do you think is closest to the truth? (1) The language says, implies, or suggests (e.g. in Implementation Advice) that the data at the location "external_symbol" will be an array of bytes. That is, it isn't a pointer even though XB would be implemented as a pointer without the Import. (2) The data at the location "external_symbol" will be an array of bytes, not because the language says anything about it, but because it's the only useful way to do it and everyone would assume that it's done that way. (3) The data at the location "external_symbol" must be a pointer to an array of bytes, because the Ada convention in the Import pragma requires that the data at location "external_symbol" follow Ada conventions for the implementation, which in this case means being stored as a pointer because that's the way the Ada compiler would do it without the Import. (4) You can't count on the compiler to treat the data at "external_symbol" one way or the other, and it's an error to write this kind of code if the program is to be portable. Thank, I appreciate your thoughts on this. **************************************************************** From: Randy Brukardt Date: Thursday, January 14, 2010 8:42 PM None of these make any sense. The use of pragma Import can have no impact on whatever is at "external_symbol" -- it is whatever it is. You really need to be asking what form the data at "external_symbol" needs to be in in order for the compiler to use it with this Import pragma. My answer would be that if the data at "external_symbol" is in fact created by the same Ada compiler and exported with an appropriate Export pragma, it has to work properly. That is, the representation has to be the same on both sides. And otherwise what it does is implementation-defined. Which means no one has any reason to assume anything about the expected representation, nor expect any sort of portability from compiler-to-compiler. Note that B.1(38.1/2) makes it the programmers responsibility that the semantics of interfacing pragmas is correct. This applies just as much to convention Ada as to any other convention. Indeed, I really don't see anything that even requires Export to Import to work, although it would seem nasty if it did not. (But note that it is possible that exceptions can't propagate through C or Fortran interfacing, to take one example. So even matching pragmas are not a guarantee.) Janus/Ada generates code similar to what you are describing here, but I suspect that the Import/Export pair actually exports the array of bytes. I think it shares the implementation with address clauses, which would do that. But I cannot be certain without a lot of research. Indeed, Janus/Ada does this sort of thing for lots of kinds of objects: ones with address clauses, renames, pragma Import and Export, dynamically sized objects. In most of those cases (and maybe all of them), the use of the pointer is treated as an implementation artifact and is hidden from the user in all ways (including things like Unchecked_Conversion and streaming). So we wouldn't necessarily say that the object is "implemented as a pointer". User expectations are another matter altogether. What's most useful is probably some version of what you describe as (2). So implementations probably ought to use (2) as the external model (there is no reason to assume or expect that the internal and external representations of objects are the same: they almost never are in Janus/Ada's code shared generics, for instance). But what makes sense for user has nothing to do with the language definition. Summary: the language requires nothing. Users might expect (2), and it's always a good idea to give users what they expect within reason, but that has nothing to do with this group. **************************************************************** From: Adam Beneschan Date: Friday, January 15, 2010 10:59 AM > None of these make any sense. The use of pragma Import can have no > impact on whatever is at "external_symbol" -- it is whatever it is. > You really need to be asking what form the data at "external_symbol" > needs to be in in order for the compiler to use it with this Import pragma. Poor wording on my part. What I meant was, what kind of data should the compiler assume is at "external_symbol" when compiling the above code. But I think you figured that out. ... > Summary: the language requires nothing. Users might expect (2), and > it's always a good idea to give users what they expect within reason, > but that has nothing to do with this group. Except that many of the people on this group are users and/or understand what users want, so I thought your opinions from experience would be valuable. But my main interest was in finding out, from those who have worked on designing the language, whether the language had anything to say about this. Thanks, Randy, for the detailed response---it's definitely helpful. **************************************************************** From: Bob Duff Date: Friday, January 15, 2010 11:48 AM > But what makes sense for user has nothing to do with the language > definition. I think I'll frame this quote and hang it on the wall! ;-) ****************************************************************