Re: Making the same mistake as the broken C interface to fortran

[Chris M Moore <zmower@ntlworld.com>]

On 04/07/2019 09:38, Simon Wright wrote:
> Chris M Moore <zmower@ntlworld.com> writes:
> 
>> On 03/07/2019 20:02, Randy Brukardt wrote:
>>> "Chris M Moore" <zmower@ntlworld.com> wrote in message
>>> news:2uYSE.298383$sJ3.119314@fx04.am4...
>>> ...
>>>> So the question is do we break the API or not?
>>>
>>> That's not the question. The question is ensuring that the Ada
>>> compiler properly implements the Fortran convention. If it does, then
>>> the API doesn't change. And if it doesn't, then fix the silly
>>> compiler (or get a different one that does the right thing). The
>>> Annex B "Implementation Advice" (specifically, B.5(22-26)) is very
>>> close to a requirement, in that the interface is not useful if one
>>> can't depend on the mapping.
>>>
>> <snip>
>>>
>>> BTW, I note that type Fortran_Character is in fact an array type, so
>>> that could be confusing some readers of the API (it surely would have
>>> confused me).
> 
> It confused the heck out of me, too. You'd've expected a warning at
> least if you use a dodgy parameter type!

Agreed.

> I did a little poking around with GCC 9.1.0:
> 
> Fortran:
> 
>        subroutine callee (c)
>        character (1), intent (in) :: c
> 
>        print *, 'parameter c is ', c
> 
>        end

I'm having flashbacks.  Send help. ;)

> Ada:
> 
> with Interfaces.Fortran;
> procedure Call is
>     procedure Callee_C (C : Character)
>     with
>       Import,
>       Convention => Fortran,
>       External_Name => "callee_";
>     procedure Callee_F (C : Interfaces.Fortran.Fortran_Character)
>     with
>       Import,
>       Convention => Fortran,
>       External_Name => "callee_";
>     procedure Callee_S (S : String)
>     with
>       Import,
>       Convention => Fortran,
>       External_Name => "callee_";
> begin
>     Callee_C ('c');

I've looked at the assembler for this.  Passing 'c' results in only a 
byte pushed to the stack.  And then (aha!) the address on the stack is 
placed in the rdi register.

>     Callee_F ((1 => 'f'));
>     Callee_F ("F string");
>     Callee_S ("A string");

These pass the address of a fixed string (in the ro text area) in the 
rdi register.

> end Call;
> 
> Result:
> 
> $ gfortran -c callee.f
> $ gnatmake -gnatwa call.adb -largs callee.o -lgfortran
> gcc -c -gnatwa call.adb
> gnatbind -x call.ali
> gnatlink call.ali callee.o -lgfortran
> $ ./call
>   parameter c is >   parameter c is f
>   parameter c is F
>   parameter c is A

So it works at the moment for the small example we have.

>> I'm sure GNAT does the right thing if you're using
>> Fortran_Character. Unfortunately the bindings use Standard.Character.
> 
> Which bindings are those?

I was looking at the LAPACK ones on sourceforge.

> I can certainly look at changing the ones in
> gnat-math-extn (Should be https://sf.net/p/gnat-math-extn, but down at
> the moment), but those are entirely internal.

I'd wait until we have conclusive proof we have a problem.  I'll do some 
more digging.

<snip>

-- 
sig pending (since 1995)