pragma import ambiguity

pragma import ambiguity

[tmoran]

One Ada compiler accepts this, another doesn't. I agree with the one that
objects.  Are we wrong?
procedure testimp is
  type logicopenm is ( clear, gl_and);
  procedure clear(mask:integer);
  pragma import(stdcall,clear,"glclear");
begin
  null;
end testimp;

Re: pragma import ambiguity

[bubble]

are you mean there are the same name symbols in a library?

I assume your library is standard winapi and writing in C not C++.
the C++ have name decoration problem
to avoid the name decoration problem

you "may" use external "C" to solve it.

like

#ifdef __cplusplus
  external "{"
#end if
                __declspec(dllexport) int clear;
                int __declspec(dllexport)  __stdcall clear();


#ifdef __cplusplus
}
end if

I think your C/C++ compiler should allow to compiler it because  C does
not allow the same name in code.



another way.
you should create a def file and there are alias names in it.





tmoran@acm.org 寫道：

> One Ada compiler accepts this, another doesn't. I agree with the one that
> objects.  Are we wrong?
> procedure testimp is
>   type logicopenm is ( clear, gl_and);
>   procedure clear(mask:integer);
>   pragma import(stdcall,clear,"glclear");
> begin
>   null;
> end testimp;

Re: pragma import ambiguity

[bubble]

 I think your C/C++ compiler should "NOT" allow to compiler it because
C does
 not allow the same name in code.

sorry missing "NOT".

bubble 寫道：

> are you mean there are the same name symbols in a library?
>
> I assume your library is standard winapi and writing in C not C++.
> the C++ have name decoration problem
> to avoid the name decoration problem
>
> you "may" use external "C" to solve it.
>
> like
>
> #ifdef __cplusplus
>   external "{"
> #end if
>                 __declspec(dllexport) int clear;
>                 int __declspec(dllexport)  __stdcall clear();
>
>
> #ifdef __cplusplus
> }
> end if
>
> I think your C/C++ compiler should allow to compiler it because  C does
> not allow the same name in code.
>
>
>
> another way.
> you should create a def file and there are alias names in it.
>
>
>
>
>
> tmoran@acm.org 寫道：
>
> > One Ada compiler accepts this, another doesn't. I agree with the one that
> > objects.  Are we wrong?
> > procedure testimp is
> >   type logicopenm is ( clear, gl_and);
> >   procedure clear(mask:integer);
> >   pragma import(stdcall,clear,"glclear");
> > begin
> >   null;
> > end testimp;

Re: pragma import ambiguity

[Pascal Obry]

bubble a écrit :
> are you mean there are the same name symbols in a library?
...

I think you got this wrong. The OP problem is that Clear is a procedure
and also a value of the enumerated type logicopenm.

I think the program is ok. A pragma import takes a local_name and this
can't be an enumeration_literal_specification. So the clear in the
pragma import is not ambigus as it can only apply to the procedure Clear.

Now it is said in RM 3.5.1(11):

<<
When called, the parameterless function associated with an enumeration
literal returns the corresponding
value of the enumeration type.
>>

But I don't think this implicit function should be taken into account here.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: pragma import ambiguity

[Dave Thompson]

On 6 Sep 2006 09:39:30 -0700, "bubble" <kuan_long@hotmail.com> wrote:
(topposted, not worth the trouble of correcting)

> are you mean there are the same name symbols in a library?
> 
> I assume your library is standard winapi and writing in C not C++.
> the C++ have name decoration problem
> to avoid the name decoration problem
> 
This wasn't the OP's problem (which was within the Ada) and he(WLOG)
didn't say anything to indicate he is using C++. But even if so:

> you "may" use external "C" to solve it.
> 
> like
> 
> #ifdef __cplusplus
>   external "{"

extern "C" {

> #end if

#endif 

>                 __declspec(dllexport) int clear;
>                 int __declspec(dllexport)  __stdcall clear();
> 
Non-standard Windows-only; but the OP _did_ imply Windows.

> 
> #ifdef __cplusplus
> }
> end if
> 
#endif

> I think your C/C++ compiler should allow to compiler it because  C does
> not allow the same name in code.
> 
Neither does C++ when using extern "C", formally called C linkage. And
even in "real C++", you can't have both a function/routine and
variable with the same name in the same namespace; overloading only
works among function/routines, not for variables or typenames.

- David.Thompson1 at worldnet.att.net

Re: pragma import ambiguity

[Frank J. Lhota]

tmoran@acm.org wrote:
> One Ada compiler accepts this, another doesn't. I agree with the one that
> objects.  Are we wrong?
> procedure testimp is
>   type logicopenm is ( clear, gl_and);
>   procedure clear(mask:integer);
>   pragma import(stdcall,clear,"glclear");
> begin
>   null;
> end testimp;

This is a tough call. Technically, an enumeration literal such as "clear" in

	type logicopenm is ( clear, gl_and);

is an implicit, parameterless function. Section B.1 of the ARM states 
"If the local_name denotes more than one entity, then the pragma Import 
is the completion of all of them", so one could argue that the import 
clause imports a subprogram for *both* the clear procedure and the 
enumeration literal. This is clearly not possible: the "clear" 
enumeration literal must be implicit.

Of course, one may argue that B.1 should not apply to enumeration 
literals, but even so, this kind of overloading is not recommended. My 
advice would be to give the enumeration literal and the procedure 
separate names.

Re: pragma import ambiguity

[Gautier]

Frank J. Lhota:

 > My advice would be to give the enumeration literal and the
 > procedure separate names.

And when not possible, the workaround is (marked *):

procedure testimp is
   type logicopenm is ( clear, gl_and);
   procedure clear(mask:integer);
   procedure glClear(mask:integer);
   procedure clear(mask:integer) renames glClear; -- *
   pragma import(stdcall,glClear,"glclear");      -- *
begin
   null;
end testimp;
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: pragma import ambiguity

[Dmitry A. Kazakov]

On Wed, 06 Sep 2006 13:34:27 -0400, Frank J. Lhota wrote:

> tmoran@acm.org wrote:
>> One Ada compiler accepts this, another doesn't. I agree with the one that
>> objects.  Are we wrong?
>> procedure testimp is
>>   type logicopenm is ( clear, gl_and);
>>   procedure clear(mask:integer);
>>   pragma import(stdcall,clear,"glclear");
>> begin
>>   null;
>> end testimp;
> 
> Of course, one may argue that B.1 should not apply to enumeration 
> literals, but even so, this kind of overloading is not recommended. My 
> advice would be to give the enumeration literal and the procedure 
> separate names.

procedure Testimp is
  procedure Clear (mask:integer);
  pragma Import (stdcall, clear, "glclear");

  type logicopenm is (clear, gl_and);
begin
   null;
end Testimp;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: pragma import ambiguity

[Adam Beneschan]

Frank J. Lhota wrote:
> tmoran@acm.org wrote:
> > One Ada compiler accepts this, another doesn't. I agree with the one that
> > objects.  Are we wrong?
> > procedure testimp is
> >   type logicopenm is ( clear, gl_and);
> >   procedure clear(mask:integer);
> >   pragma import(stdcall,clear,"glclear");
> > begin
> >   null;
> > end testimp;
>
> This is a tough call. Technically, an enumeration literal such as "clear" in
>
> 	type logicopenm is ( clear, gl_and);
>
> is an implicit, parameterless function. Section B.1 of the ARM states
> "If the local_name denotes more than one entity, then the pragma Import
> is the completion of all of them", so one could argue that the import
> clause imports a subprogram for *both* the clear procedure and the
> enumeration literal. This is clearly not possible: the "clear"
> enumeration literal must be implicit.

Not quite; 3.5.1(6) says that the declaration of "clear" is explicit.
This makes a difference because of 3.11.1, which says that implicit
declarations may not have completions, but completions are allowed "in
principle" for any kind of explicit declaration, but only if there is
an implementation for that sort of declaration (B.1(22)).  Also, 6.3.1
says that the function declaration that arises from the enumeration
literal declaration has a default calling convention of Intrinsic, but
it also says that default calling conventions can be overridden,
although I can't see how it could make sense to override the default
calling convention for an enumeration literal, or for that matter most
or all of the other types of subprograms whose default calling
convention is Intrinsic.  So I'm not sure why the language allows this
"in principle".  Anyway, the language isn't clear on whether Import can
be applied to an enumeration literal.

I do believe, though, that it would be wrong for a compiler to reject
this:

    type logicopennm is (clear, gl_and);
    pragma import (stdcall, clear, "glclear");

when there's no overloading involved, but to accept the same pragma
when it can be applied both to a subprogram named "clear" and to the
enumeration literal.  The language does say that Import is the
completion of all entities denoted by the name, and if such a
completion is illegal for any denoted entity, then the compiler has to
reject the pragma.

                             -- Adam

Re: pragma import ambiguity

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:1157657721.734036.128160@h48g2000cwc.googlegroups.com...
> Also, 6.3.1
> says that the function declaration that arises from the enumeration
> literal declaration has a default calling convention of Intrinsic, but
> it also says that default calling conventions can be overridden,
> although I can't see how it could make sense to override the default
> calling convention for an enumeration literal, or for that matter most
> or all of the other types of subprograms whose default calling
> convention is Intrinsic.  So I'm not sure why the language allows this
> "in principle".

Probably because there are Intrinsic routines where it does make sense to
override the calling convention (i.e. inherited routines).

> Anyway, the language isn't clear on whether Import can be applied to an
enumeration literal.

My understanding is that the intent is that the language allows
Import/Export to be applied to *any* entity. The theory being that we didn't
want to predict what we might be able to interface with in the future. For
instance, it might make sense to Import an exception on some implementations
(say, if C++ and Ada exceptions are implemented the same way). Similarly, it
might make sense to import literal values from another language, so I
suppose it could mean something somewhere.

But of course, these pragmas are required to work only for limited set of
entities, and enumeration literals isn't one of them.

> I do believe, though, that it would be wrong for a compiler to reject
this:
>
>     type logicopennm is (clear, gl_and);
>     pragma import (stdcall, clear, "glclear");
>
> when there's no overloading involved, but to accept the same pragma
> when it can be applied both to a subprogram named "clear" and to the
> enumeration literal.  The language does say that Import is the
> completion of all entities denoted by the name, and if such a
> completion is illegal for any denoted entity, then the compiler has to
> reject the pragma.


I agree with this.

                  Randy.