From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!85.12.16.68.MISMATCH!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.am4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx26.am4.POSTED!not-for-mail Subject: Re: Making the same mistake as the broken C interface to fortran Newsgroups: comp.lang.ada References: <2uYSE.298383$sJ3.119314@fx04.am4> <499TE.1270744$Ud5.547915@fx12.am4> From: Chris M Moore User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Message-ID: X-Complaints-To: http://netreport.virginmedia.com NNTP-Posting-Date: Fri, 05 Jul 2019 13:49:40 UTC Organization: virginmedia.com Date: Fri, 5 Jul 2019 14:49:41 +0100 X-Received-Bytes: 4168 X-Received-Body-CRC: 3099286864 Xref: reader01.eternal-september.org comp.lang.ada:56821 Date: 2019-07-05T14:49:41+01:00 List-Id: On 04/07/2019 09:38, Simon Wright wrote: > Chris M Moore writes: > >> On 03/07/2019 20:02, Randy Brukardt wrote: >>> "Chris M Moore" 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. >>> >> >>> >>> 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. -- sig pending (since 1995)