This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Enhancement suggestion: -fno-gnu-intrinsics
On Thu, Feb 19, 2009 at 08:07:19PM +0000, William Brendling wrote:
> On Thu, Feb 19, 2009 at 2:25 PM, Steve Kargl
> <sgk@troutmask.apl.washington.edu> wrote:
> > On Thu, Feb 19, 2009 at 01:58:49PM +0000, William Brendling wrote:
> >>
> >>
> >> The problem is that my code uses subroutines with names that conflict
> >> with some of the GNU extensions to the intrinsics.
> >>
> >> I know that I can solve the problem by adding explicit declaration of
> >> my routine names (e.g. 'EXTERNAL UNLINK') in my code. However, since
> >> the problem is caused by a non-standard GNU extension to the
> >> intrinsics namespace, it would be nice if there was an option to turn
> >> these off, without disabling support for legacy coding styles.
> >>
> >
> > The Fortran Standard specifies a list of intrinsic subprograms that
> > a conforming implementation must supply. ?The Standard does not prohibit
> > an implementation from providing any additional intrinsic subprograms.
> > If you want only those subprograms listed in the Standard, then use
> > -std=f95 or -std=f2003 and fix your program with EXTERNAL UNLINK.
> > The obvious benefit to fixing your code is portability.
> >
> So, in order to ensure portability, I must use EXTERNAL statements to
> declare the names of every one of my routines that I call, in case
> some compiler happens to define an intrinsic with the same name?
Well, the intent of EXTERNAL is to tell the compiler that the
symbol will be associated with a user supplied routine. Given
that the (Unix) system call unlink(2) first appeared in Version
6 AT&T Unix some 30 to 40 years ago, one might expect a Fortran
compiler to include UNLINK in its list of intrinsic subprograms.
So, yes, for portability use of EXTERNAL is recommended (by at
least me).
> Presumably in good modern Fortran 95 I would use an interface
> definition instead? Still I suppose that is what C/C++ does with
> header files.
In modern Fortran, I'd recommend that the subroutine should be
encapsulated in a MODULE where everything is PRIVATE except
for a list of specific PUBLIC entities. The advantages include
a clean namespace and an explicit interface.
--
Steve