(j3.2006) binding labels and global identifiers

[Bill Long]

On 6/20/11 3:38 PM, Van Snyder wrote:
>
> On Sun, 2011-06-19 at 04:22 -0700, Bill Long wrote:
>>
>> On 6/19/11 2:36 AM, mickistjames at gmail.com wrote:
>>> Robert Corbett wrote:
>>>
>>>   >Is the program presented above intended to be standard-
>>>   >conforming?
>>>
>>> I would agree with Malcolm and answer no.
>>>
>>
>
> 16.2p1 says that a binding label is a global identifier, and the name of
> an external procedure is a global identifier.  16.2p2 says two global
> identifiers can't be the same.
>
> Neither paragraph addresses the question of an identifier the processor
> derives from the identifiers specified by the standard.
>
> So if the processor mangles an identifier that the standard says is a
> global identifier, and manages to create one that's the same as a
> different global identifier specified in your program, I'd be inclined
> to say the processor, not the program or the standard, is the culprit.
>

I agree that is what the standard says.  The original question is 
whether it was the original intention that this particular example 
should work.  Multiple people have said the answer is no.



>> While one might imagine some scheme to allow the case in the original
>> example to work (since global variables and procedures are different
>> sorts of objects), the even worse example of an interface block for a
>> function with a binding label of subr_ and a function named subr seems
>> intractable in an environment where the Fortran processor appends an
>> underscore to the end of a procedure name.  The irony is that the
>> convention of adding an underscore was designed to prevent (accidental)
>> interoperability.
>
> This was a bad idea from the outset.  It's a shame it got perpetuated.
>

I certainly agree that is was a bad idea.  But, given that the situation 
exists, the question is what to do about it.  We have certainly 
disallowed things in the past based on implementation difficulties or 
undue burden on vendors or users.

In this case, there seem to be a couple of resolution paths:

1) Say it really is the rule and encourage compiler vendors to support 
something like the gfortran option "-fno-underscoring".   Though over 
half of their man page entry consists of reasons to not use this option. 
  One is the possibility you would end up calling a function written in 
C which was what the original convention is intended to prevent. Another 
notes that you would be incompatible with a lot of already compiled 
legacy library code.  [The Swedes did bite the bullet and switch to 
driving on the right side of the road, so I'm no saying this is 
impossible.  But I think the change would need to be coordinated with 
the Unix community.]

2) Figure out some way to say "don't do that" to programmers without 
looking too arbitrary.

In the mean time, I can tell our users that our 'processor' has a bug in 
this case and what they should do to avoid being affected.

Cheers,
Bill





>>
>>
>>> R303 says that underscores may be used as a significant
>>> character in a name, but I see no provision for low lines,
>>> so if "_" in a binding label is a low line then the functionality
>>> to bind to C names with underscores is simply missing.
>>>
>>> Okay, that may have been a joke, but
>>> "subr_" is not a name in the line
>>> REAL, BIND(C, NAME="subr_") :: x = 0.1
>>
>> Right, it is a "binding label".
>>
>>> it is a scalar-char-initialization-expr or some such, so
>>> an implementation that wants to outlaw scalar-char-initialization-expr's
>>> that mimic linker-constructed names with low lines would seem
>>> to be on narrow but reasonable ground. Is there any expectation that
>>> absolutely
>>> any initialization expr is legal?
>>
>> No. The string has to be legal as a name of the corresponding object in C.
>>
>> Cheers,
>> Bill
>>
>>> Seems like control characters
>>> are legal in initialization expr's but not in names, if so that would
>>> already be a special case to handle.
>>>
>>> Micki
>>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101