(j3.2006) binding labels and global identifiers

[Craig Dedo]

> -----Original Message-----
> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org] On Behalf Of Van
> Snyder
> Sent: Wednesday, June 22, 2011 13:19
> To: fortran standards email list for J3
> Subject: Re: (j3.2006) binding labels and global identifiers
> 
> 
> On Wed, 2011-06-22 at 01:44 -0700, Malcolm Cohen wrote:
> >
> > >> 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.
> >
> > That's your opinion.  I disagree; while not the name mangling scheme I would
> > have designed if starting from scratch, it is a reasonable one.
> 
> Fortran 90 needs to compose names for module procedures, but I don't
> understand why any processor, either pre-Fortran 90 or post-Fortran 90,
> needs to mangle names of external procedures.
> 
> I can't imagine how I got along for a decade on the 7094, and two on the
> 1108, without any name mangling.
> 

	I can't understand it either.  Both OpenVMS and Windows do not change the linker
name of any global or external identifier and both OSes have been around for a long time.

	Further, the default behavior of the OpenVMS Linker Utility is that global
identifiers are case INSENSITIVE (OpenVMS Linker Utility Manual 8.3, p. LINKER-59).  You
have to use the CASE_SENSITIVE=YES linker option in a link options file in order to make
global symbols case sensitive during a link operation.

	I have done a lot of programming under OpenVMS both in Fortran and C.  I have
never had a problem with the linker linking into a different procedure than the one I
intended to link to by mistake.  I have also had plenty of experience with old C code that
used lower-case spelling for OpenVMS Run Time Library procedures (e.g., LIB$WAIT()) and
the called RTL procedures are linked in just fine.

	This experience leads me to wonder if the habitual Unix convention really needs to
be continued.  How difficult and costly would it be for the Unix processors and linkers to
change their behavior so that they do not change global identifiers?

Sincerely,
Craig T. Dedo
17130 W. Burleigh Place
P. O. Box 423                  Mobile Phone:  (414) 412-5869
Brookfield, WI   53008-0423    E-mail:  <craig at ctdedo.com>
USA
Linked-In:  http://www.linkedin.com/in/craigdedo