Multiple pragma Imports

Multiple pragma Imports

[dewar]

I thought I would give a heads up on a problem we
have found in GNAT that we suspect exists in other
compilers (certainly DEC Ada 83 for example). Consider
the following:

   function Junk return Integer;
   pragma Import (C, Junk, "junk");

   function Junk return My_Integer;
   pragma Import (C, Junk, "junk");

We have seen this pattern in several bindings, including
the x11 bindings from Intermetrics. But the above code is
in fact illegal.

The problem is that the second pragma Import applies to
*both* of the function declarations. This is a consequence
of the last sentence in B.1(22):

  If the local_name denotes more than one entity, then
  the pragma Import is the completion of all of them.

This means that we have two pragma Imports for the first
function declaration, but this violates the last sentence
of 3.11(7):

  At most one completion is allowed for a given
  declaration.

We have fixed GNAT to properly reject the above program,
but we suspect that the above construction is quite
common, and that other compilers besides GNAT have
accepted this in the past.

So this is a heads up, and an invitation for discussion.
(to me, I think it would be far better if the rule were
that pragma Import acts as a completion only to entities
which have not already been completed, but unfortunately
that is not the way the language is defined).

The proper coding for the case where the same pragma Import
is expected to apply to all entities is simply to give just
one such pragma Import, so all you need to do is to remove
the first pragma Import to make the above code legal, and
to make it do what you want.

In the case where there are different imports, as in:

   function Junk return Integer;
   pragma Import (C, Junk, "junk1");

   function Junk return My_Integer;
   pragma Import (C, Junk, "junk2");

This is still of course illegal, but GNAT was silently
ignoring the first pragma Import completely, which is
definitely not what is wanted. The proper way of achieving
the effect of the second example is to use renaming so that
the entity in the pragma Import is unique.

I would be delighted to find out that my analysis is
incorrect here, but I am pretty sure it is right, and I
have discussed it with other folk, including Bob Duff,
before posting here.

Robert Dewar
Ada Core Technologies




-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Multiple pragma Imports

[Jerry van Dijk]

dewar@gnat.com wrote:

:    function Junk return Integer;
:    pragma Import (C, Junk, "junk");

:    function Junk return My_Integer;
:    pragma Import (C, Junk, "junk");

The real problem, IMHO, is that you can overload the Ada
subprogram, but not the interfacing pragma.

: We have fixed GNAT to properly reject the above program,
: but we suspect that the above construction is quite
: common, and that other compilers besides GNAT have
: accepted this in the past.

What I (but then, who am I... :-) would like to see in an ideal world is:

Short Term:

a) GNAT follows the RM;
b) GNAT issuing an error if an interfacing pragma matches more
   than one subprogram signature;
c) GNAT having a switch to revert to its old behaviour to enable
   use of current bindings, to be fased out at some later date;
d) Other compilers following GNAT.

Long Term:

Serious discussion for the ARG on this subject.

I do not think the idea of having the pragma apply to the the 
next uncompleted subprogram is the right one, as this would force
the pragma to follow the subprogram declaration immediately. Whereas
it is common idiom to put the interfacing pragmas in the private part
of a specification. 

To get the behaviour I would like to see, the interfacing pragmas should
somehow be able to discern between the different subprogram signatures.
Maybe this calls for some extended interfacing pragma form, to be 
implemented by general consensus. 

But, I immediately admit I'm no language expert...
  
Jerry.

-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada
-- Ada & Win32: http://stad.dsl.nl/~jvandyk

Re: Multiple pragma Imports

[Larry Kilgallen]

In article <F4LKJL.7z@jvdsys.stuyts.nl>, jerry@jvdsys.stuyts.nl (Jerry van Dijk) writes:

> To get the behaviour I would like to see, the interfacing pragmas should
> somehow be able to discern between the different subprogram signatures.
> Maybe this calls for some extended interfacing pragma form, to be 
> implemented by general consensus. 

The real world need is vanishingly small for calling external
subprograms which share a name but not interface characteristics.

Larry Kilgallen

Re: Multiple pragma Imports

[Jerry van Dijk]

Larry Kilgallen (kilgallen@eisner.decus.org) wrote:

: > To get the behaviour I would like to see, the interfacing pragmas should
: > somehow be able to discern between the different subprogram signatures.
: > Maybe this calls for some extended interfacing pragma form, to be 
: > implemented by general consensus. 

: The real world need is vanishingly small for calling external
: subprograms which share a name but not interface characteristics.

What I was thinking of was situations like:

int   min (int a, int b);
float min (float a, float b);

and such.

Jerry.

-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada
-- Ada & Win32: http://stad.dsl.nl/~jvandyk

Re: Multiple pragma Imports

[Tom Moran]

A fairly common situation is that an Ada binding has separated two
distinct types, which are the same in C for some function.  Thus the
Ada binding might have types Server_Socket and Client_Socket, which
are opened and used with different parameters, but are closed by a C
function with a single parameter.  Then a naive thin binding might try
to have
  procedure Close(Client : in out Client_Socket);
  pragma import(C, Close, "SClose");
  procedure Close(Server : in out Server_Socket);
  pragma import(C, Close, "SClose");
As I understand Robert Dewar's message, this is in fact illegal Ada,
though it has been accepted by more than one compiler in the past.
Something like
  procedure Close(Client : in out Client_Socket);
  pragma import(C, Close, "SClose");
  procedure Close(Server : in out Server_Socket) is
  begin
     Close(Client_Socket(Server));  -- appropriate type conversion
  end Close;
 would be needed.

Re: Multiple pragma Imports

[dewar]

In article <F4LKJL.7z@jvdsys.stuyts.nl>,
  jerry@jvdsys.stuyts.nl (Jerry van Dijk) wrote:
> a) GNAT follows the RM;
> b) GNAT issuing an error if an interfacing pragma matches
     more than one subprogram signature;

That seems a bit confused, we can't issue an error message
for this, since it is perfectly normal. It is not even
right to issue a warning, since it is quite common to use
the same Import for a function and procedure, and perfectly
legitimate (one might almost say a standard idiom for C!)

> c) GNAT having a switch to revert to its old behaviour to
     enable use of current bindings, to be phased out at
     some later date;

Since what GNAT was doing is clearly wrong, this seems a
bad idea. It is either trivial to fix the binding, or not
quite trivial (use renamings), but in the latter case, GNAT
was certainly NOT doing what the programmer intended, so it
is far better to give an error.

I don't think there is any language issue here.
Considerations of upwards compatibility make it impractical
to fix this problem even if you regard it as a problem.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Multiple pragma Imports

[dewar]

In article <3686918c.1630214@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
>  Then a naive thin binding might try to have
>   procedure Close(Client : in out Client_Socket);
>   pragma import(C, Close, "SClose");
>   procedure Close(Server : in out Server_Socket);
>   pragma import(C, Close, "SClose");

> As I understand Robert Dewar's message, this is in fact
> illegal Ada, though it has been accepted by more than one
> compiler in the past.

> Something like
>   procedure Close(Client : in out Client_Socket);
>   pragma import(C, Close, "SClose");
>   procedure Close(Server : in out Server_Socket) is
>   begin
>      Close(Client_Socket(Server));  -- appropriate type
>                                               conversion
>   end Close;
>  would be needed.


No, no, please don't make this sound more complicated
or annoying than it is!!! The fix is much simpler than
that, just leave out the first pragma Import, that's the
end of it!

>   procedure Close(Client : in out Client_Socket);
>   procedure Close(Server : in out Server_Socket);
>   pragma import(C, Close, "SClose");

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Multiple pragma Imports

[dewar]

In article <F4MsBB.6D@jvdsys.stuyts.nl>,
  jerry@jvdsys.stuyts.nl (Jerry van Dijk) wrote:
> What I was thinking of was situations like:
>
> int   min (int a, int b);
> float min (float a, float b);
>
> and such.
>
> Jerry.


But that situation is quite standard, and is the one where
*different* pragma Imports must be used. The familiar and
intended way of solving this problem is by using renames so
that the pragmas refer to unique names.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Multiple pragma Imports

[Tom Moran]

>We have seen this pattern in several bindings, including
I'm pleased to comment that this does not occur in the CLAW bindings
to Windows.

Re: Multiple pragma Imports

[Jerry van Dijk]

dewar@gnat.com wrote:

:   jerry@jvdsys.stuyts.nl (Jerry van Dijk) wrote:
: > What I was thinking of was situations like:
: >
: > int   min (int a, int b);
: > float min (float a, float b);

: But that situation is quite standard, and is the one where
: *different* pragma Imports must be used. The familiar and
: intended way of solving this problem is by using renames so
: that the pragmas refer to unique names.

Aha, now I see what you meant. 

-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada
-- Ada & Win32: http://stad.dsl.nl/~jvandyk

Re: Multiple pragma Imports

[Matthew Heaney]

dewar@gnat.com writes:

> I thought I would give a heads up on a problem we
> have found in GNAT that we suspect exists in other
> compilers (certainly DEC Ada 83 for example). Consider
> the following:
> 
>    function Junk return Integer;
>    pragma Import (C, Junk, "junk");
> 
>    function Junk return My_Integer;
>    pragma Import (C, Junk, "junk");
> 
> We have seen this pattern in several bindings, including
> the x11 bindings from Intermetrics. But the above code is
> in fact illegal.

[snip]

> I would be delighted to find out that my analysis is
> incorrect here, but I am pretty sure it is right, and I
> have discussed it with other folk, including Bob Duff,
> before posting here.


I really miss the DEC pragmas here, where you could specify the argument
type, the return type (for a function), and even the argument passing
mechanism, right there in the pragma.  

The Import pragma seems a bit anemic (as the example above
demonstrates), and I would have preferred that DEC pragmas been designed
into the language.

I've never liked the fact that one pragma applies to multiple
subprograms, for example:

  <declare a few "+" functions>
  <declare a few "-" functions>

private

  pragma Inline ("+");
  pragma Inline ("-");


I'd rather be able to specify each subprogram individually in the
pragma.

Re: Multiple pragma Imports

[Robert I. Eachus]

In article <m3r9t8whzw.fsf@mheaney.ni.net> Matthew Heaney <matthew_heaney@acm.org> writes:

  > I've never liked the fact that one pragma applies to multiple
  > subprograms, for example:

  >   <declare a few "+" functions>
  >   <declare a few "-" functions>
  > private
  >   pragma Inline ("+");
  >   pragma Inline ("-");

  > I'd rather be able to specify each subprogram individually in the
  > pragma.

  If you need to do this, the way to do it is to rename the operations
you want inlined in the private part, then apply inline to the renamed
versions.  That this is possible is not obvious from the RM, that is
would be nice if it were more elegant is agreed.  (You often can order
the declarations so that the pragma is in the middle, and only applies
to those above it, but this doesn't work if you want the pragma in the
private part.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Multiple pragma Imports

[dewar]

In article <m3r9t8whzw.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> I really miss the DEC pragmas here, where you could
> specify the argument type, the return type (for a
> function), and even the argument passing
> mechanism, right there in the pragma.

Well if you miss them too much, use GNAT! GNAT implements
the full set of DEC Ada 83 pragmas and attributes, and most
of them, including the ones you refer too here, can be used
on all GNAT targets.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own