Re: Several questions about character C binding

"Steven Correll" <steven.correll@xxxxxxxxx> wrote in message
news:73214c62-ed98-4e04-a49a-5fda26ff66ea@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I don't see any bug in the standard. To repeat: The rule you cited
from 15.2.6 says that the number of Fortran "dummy arguments" and the
number of C "formal parameters" (each term has a precise definition in
its respective standard) must be the same: that's a restriction on the
programmer. It does not say that the number of machine-level arguments
must also be the same (which would be a restriction on the
implementation.)

Again and again we see questions about interfacing Fortran character
arguments with other languages. Even Fortran-to-Fortran can be
problematic. The reason, of course, stems from Fortran 77 which
allowed assumed length character dummy variables but not explicit
interfaces. Since any character actual argument could, for all the
compiler knows, be associated with an assumed length dummy argument,
its length had to be passed even though the dummy argument wasn't
assumed length. These lengths have to be passed by any procedure
that calls a Fortran procedure, or taken into account by any
procedure that is called from Fortran. Unless there is some
mechanism provided to the Fortran compiler to turn off these
lengths. ifort has one, viz. !DEC$ ATTRIBUTES REFERENCE :: string
to turn off the passing of the length for string. Now you are
telling me that this problem has not in fact been solved by the
bind(C) stuff, even though it obviously forbids character variables
with LEN /= 1 just to enable the lengths to be turned off on both
sides. You know this goes both ways: if a Fortran caller is allowed
to pass the extra lengths even though they are superfluous, a
Fortran callee, even though it was defined as bind(C) should be
allowed to attempt to read those lengths, as in my example which
you naturally elided.

If a Fortran compiler claims to be interoperable with a C compiler
while using STDCALL, and it executes a conforming program incorrectly
due to extra machine-level arguments, then the compiler fails to
conform to the standard: not because of the rule in 15.2.6, but
because it executes the program incorrectly. On Linux (for example)
where extra arguments are harmless, the compiler is free to pass them.

On 64-bit Windows extra arguments are harmless. Not so on Linux where
extra arguments in xmm registers and the function is unprototyped or
varargs, but bind(C) doesn't consider such functions, so I'll let it
slide. Passing a different number of arguments than specified in the
bind(C) interface and failing as a consequence but not considering
that to be a violation of the rule about number of arguments matching,
well if you say so. You know, a compiler could return .TRUE. for

logical function is_broken()
is_broken=transfer(transfer(2,.TRUE.).NEQV.transfer(4,.TRUE.),0)==1
end

and one could argue forever about whether that is reasonable
behavior, but it would not mean that the compiler was usable.

You may reasonably say that a Windows Fortran compiler isn't useful to
you unless it supports STDCALL calls to Windows OS functions, but you
can't say it violates the standard. As a thought experiment, imagine
an interoperable Fortran interpreter and C interpreter which both work
by emitting code for a Java-like virtual machine, rather than machine
language. Imagine that the C interpreter conforms to the C standard,
providing all the C library functions, but not the Windows OS
functions (the C standard doesn't require them.) It's difficult to
believe that the Fortran standard could, under the rubric of
interoperability, compel the Fortran processor to do something which
the C processor itself is not required to do.

But it would be so cool if we could force Linux to implement the
Windows OS functions, because then it might be almost usable! Maybe
you should rethink your stance on that issue.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


.

Relevant Pages

  • Re: Bugs at my web site
    ... what might prove fatal with a new compiler. ... that I think they are good traditional fortran, whatever some standard might ... I hope the g95 people, after taking a good long vacation to ...
    (comp.lang.fortran)
  • Re: Integer Coersion
    ... and as this is Fortran not Delphi, ... vaguely standard conforming. ... Your compiler supports SIZEOF as do several others including my ... to be other than 8bits when cheap memory came on the scene and BURIED ...
    (comp.lang.fortran)
  • Re: Starting to doubt fortran
    ... that there were absolutely no "clever" tricks. ... time a new version of the vendors C compiler comes out. ... Fortran), it could be reliably depended upon in a portable way. ... That's beyond the standard, but many tend to be so ...
    (comp.lang.fortran)
  • Re: g77 compliance?
    ... > claims that code conforms to a standard doesn't mean that it actually ... I must admit i'm not the biggest fan of Fortran. ... > your experience leads you to suspect compiler conformance as a first ...
    (comp.lang.fortran)
  • Re: A few syntax questions
    ... I think putting them in the 'action-stmt' syntax rule ... If I were to redo the bnf from scratch, ... I guess that means that a standard conforming compiler is supposed to overflow. ... I am hoping that F2003 features will regain some respect for Fortran in CS departments,, and not just be coinsidered an old archaic language for old programs, but such strong support of archaic Fortran standards is a major reason why Fortran popularity continues to dwindle. ...
    (comp.lang.fortran)