(j3.2006) Interop observation

[Keith Bierman]

> possibility (if anything is done at all) is simply

Nothing is a good option since its a topic for the linker notes. But (assuming action) rather than giving advice about how to avoid the problem on some class of processors, I'd put in a note for a "typical" POSIX style Processor which fails.  

Sent from my iPad

On Feb 6, 2012, at 4:33 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

> As was observed in an earlier discussion on this topic, we don't want to
> add anything normative, or at least not imperatively normative, that
> might result in essentially all vendors needing to revise their
> processors just to try to outwit people who are trying to break the
> system.
> 
> One possibility (if anything is done at all) is simply to advise that a
> binding name for a Fortran procedure ought to be in mixed case, in the
> hope that most processors will produce their linker names in a single
> case.  I've seen all upper case, all lower case, with and without
> various numbers of underscores, both before and after the Fortran name,
> but never a mixed-case linker name.
> 
> Less desirable, but perhaps more helpful, would be to augment that note
> with a recommendation (not a requirement) that processors do not use
> mixed case in their linker names for non-BIND procedures or common
> blocks.
> 
> On Mon, 2012-02-06 at 15:15 -0800, Keith Bierman wrote:
>> Obviously highly platform dependent. But unix flavored environments
>> are common enough that a note wouldn't be unreasonable (IMNSO )
>> 
>> Sent from my iPad
>> 
>> On Feb 6, 2012, at 4:07 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
>> Which fails
>>> A colleague has observed that it's not terribly difficult to construct a
>>> duplicate definition using interop features.
>>> 
>>> The example was
>>> 
>>>   SUBROUTINE AnyNamesubf(i)BIND(C,NAME="csubf_")
>>>   USE, INTRINSIC :: iso_c_binding, ONLY: c_int
>>> 
>>>     INTEGER(c_int) :: i
>>>     CALL Csubf(i)
>>>   END SUBROUTINE AnyNamesubf
>>> 
>>> where Csubf was a non-interoperable Fortran external subroutine.
>>> 
>>> I don't think this is a normative issue for the standard, but should we
>>> put a note somewhere that might help people not create these?  Maybe
>>> something like advising not to give binding names to Fortran procedures
>>> that are all lower case (or all upper case) and are sufficiently similar
>>> to the external names of non-interoperable Fortran external procedures
>>> that the linker might be sent the same name for both of them.
>>> 
>>> 
>>> _______________________________________________
>>> J3 mailing list
>>> J3 at j3-fortran.org
>>> http://j3-fortran.org/mailman/listinfo/j3IMNS
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20120206/4e63efe4/attachment.html>