From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11602 invoked by alias); 7 Apr 2009 09:12:14 -0000 Received: (qmail 11548 invoked by uid 48); 7 Apr 2009 09:12:03 -0000 Date: Tue, 07 Apr 2009 09:12:00 -0000 Message-ID: <20090407091203.11547.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/39670] dollar sign in entities is not recognized when it is first symbol In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dominiq at lps dot ens dot fr" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-04/txt/msg00572.txt.bz2 ------- Comment #3 from dominiq at lps dot ens dot fr 2009-04-07 09:12 ------- > Question is, if this is allowed at all. In comparison: digits are allowed in > function names, but not as the first character; 'FUNCTION f3()' is valid, > 'FUNCTION 3f()' is not. My fortran book says: names must consist of between 1 and 31 alphanumeric characters (letters, underscores, and numerals) of which the first MUST BE A LETTER. > Does this apply to '$' as well? Since '$' is an extension, you know the answer! It is outside the scope of the standard. BTW what should be the implict type of a variable starting with a $? Now I am not sure that, in the relics of past, names starting with a '$' had some side effects. I don't think it is likely to change this extension in gfortran. For the legacy code, the workaround depends on the kind of the variables starting with a '$'. If they are all of the same kind (say integer) then it is trivial with you favorite editor to replace all the '$name' by 'izzname' or 'i$name' (may be with some filters if you have $ elsewhere). > My personal opinion is that the Fortran compiler's primary use is support of the legacy code. This is your personnal opinion, not mine and probably not of anyone coding in fortran. In addition I have always been very suspicious about the validity of the port of such "legacy" codes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39670