Re: Several questions about character C binding

"Steven Correll" <steven.corr...@xxxxxxxxx> wrote in message

news:8a63aa03-cec1-45b2-8fd8-
d3862837ed29@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The number of Fortran "dummy arguments" must match the number of C
"formal parameters", but a Fortran dummy argument may correspond to
zero, one, or many ABI "arguments."

On Jan 18, 4:18 pm, "James Van Buskirk" <not_va...@xxxxxxxxxxx> wrote:
I just can't believe you made this comment. Do you think there is
some kind of bug in the standard due to which after the whole of
chpater 15 (on C interop) as well as the extra effort made in sections
12.4.1.2 and 12.4.1.5 to allow interoperability of character scalars
with C strings it just doesn't work? If so, you should inform the
committee so that they can fix it.

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.)

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.

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.
.

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)