In the opinion of many experienced Fortran users,
-fno-backslash should be the default, not
as currently set by
First of all, you can always specify
-fno-backslash to turn off this processing.
Despite not being within the spirit (though apparently within the
letter) of the ANSI FORTRAN 77 standard,
g77 defaults to
-fbackslash because that is what most UNIX
default to, and apparently lots of code depends on this feature.
This is a particularly troubling issue.
The use of a C construct in the midst of Fortran code
is bad enough, worse when it makes existing Fortran
programs stop working (as happens when programs written
for non-UNIX systems are ported to UNIX systems with
compilers that provide the
as the default--sometimes with no option to turn it off).
The author of GNU Fortran wished, for reasons of linguistic
purity, to make
-fno-backslash the default for GNU
Fortran and thus require users of UNIX
-fbackslash to get the UNIX behavior.
However, the realization that
g77 is intended as
a replacement for UNIX
f77, caused the author
to choose to make
g77 as compatible with
f77 as feasible, which meant making
The primary focus on compatibility is at the source-code
level, and the question became "What will users expect
a replacement for
f77 to do, by default?"
Although at least one UNIX
f77 does not provide
-fbackslash as a default, it appears that
the majority of them do, which suggests that
the majority of code that is compiled by UNIX
-fbackslash to be the default.
It is probably the case that more code exists
that would not work with
in force than code that requires it be in force.
However, most of that code is not being compiled
and when it is, new build procedures (shell scripts,
makefiles, and so on) must be set up anyway so that
they work under UNIX.
That makes a much more natural and safe opportunity for
non-UNIX users to adapt their build procedures for
g77's default of
-fbackslash than would
exist for the majority of UNIX
f77 users who
would have to modify existing, working build procedures
to explicitly specify
-fbackslash if that was
not the default.
One suggestion has been to configure the default for
-fbackslash (and perhaps other options as well)
based on the configuration of
This is technically quite straightforward, but will be avoided even in cases where not configuring defaults to be dependent on a particular configuration greatly inconveniences some users of legacy code.
Many users appreciate the GNU compilers because they provide an environment that is uniform across machines. These users would be inconvenienced if the compiler treated things like the format of the source code differently on certain machines.
Occasionally users write programs intended only for a particular machine
On these occasions, the users would benefit if the GNU Fortran compiler
were to support by default the same dialect as the other compilers on
But such applications are rare.
And users writing a
program to run on more than one type of machine cannot possibly benefit
from this kind of compatibility.
(This is consistent with the design goals for
To change them for
g77, you must first change them
Do not ask the maintainers of
g77 to do this for you,
or to disassociate
g77 from the widely understood, if
not widely agreed-upon, goals for GNU compilers in general.)
This is why GNU Fortran does and will treat backslashes in the same fashion on all types of machines (by default). See Direction of Language Development, for more information on this overall philosophy guiding the development of the GNU Fortran language.
Of course, users strongly concerned about portability should indicate explicitly in their build procedures which options are expected by their source code, or write source code that has as few such expectations as possible.
For example, avoid writing code that depends on backslash (
being interpreted either way in particular, such as by
starting a program unit with:
CHARACTER BACKSL PARAMETER (BACKSL = '\\')
Then, use concatenation of
BACKSL anyplace a backslash
In this way, users can write programs which have the same meaning
in many Fortran dialects.
(However, this technique does not work for Hollerith constants--which is just as well, since the only generally portable uses for Hollerith constants are in places where character constants can and should be used instead, for readability.)