my example test.f95 is 5 lines long:

module globalknowledgeofletters
  character(len=26), parameter :: ABC_upper="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
  character(len=26), parameter :: abc_lower="abcdefghijklmnopqrstuvwxyz"
  character(len=10), parameter :: numbers="0123456789"
end module globalknowledgeofletters



ftnchek test.f95 
returns many errors. 
I do not understand these:


==========================
FTNCHEK Version 3.3 November 2004

File test.f95:
      1 module globalknowledgeofletters
        ^
Error near line 1 col 1 file test.f95: identifier 
 MODULEGLOBALKNOWLEDGEOFLETTERS has embedded space
      2   character(len=26), parameter :: ABC_upper="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
          ^
Error near line 2 col 3 file test.f95: syntax error, unexpected end of
 statement, expecting pointer assignment or '='
      5 end module globalknowledgeofletters
        ^
Error near line 5 col 1 file test.f95: identifier 
 ENDMODULEGLOBALKNOWLEDGEOFLETTERS has embedded space
                                           ^
Error near line 5 col 36 file test.f95: syntax error, unexpected end of
 statement, expecting pointer assignment or '='
Error near line 5 file test.f95: missing END statement inserted at end of file
Warning near line 5 file test.f95: Module contains no executable statements
....
==========================


btw. this minimal example is part of a code, that has the same errormessages in ftnchek, but f95 compiles without any claim.

Who can help me? 
Thank you,

-- 
Jonas Stein <news@jonasstein.de>

Jonas Stein wrote:

> 
> my example test.f95 is 5 lines long:
> 
> module globalknowledgeofletters
>   character(len=26), parameter :: ABC_upper="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
>   character(len=26), parameter :: abc_lower="abcdefghijklmnopqrstuvwxyz"
>   character(len=10), parameter :: numbers="0123456789"
> end module globalknowledgeofletters
> 
> 
> 
> ftnchek test.f95
> returns many errors.
> I do not understand these:

As far as I know, ftnchek was designed only for FORTRAN-77.


-- 
François Jacq
email : first name . last name at irsn . fr

Jonas Stein <news@jonasstein.de> wrote:

> ...errormessages in ftnchek,
> but f95 compiles without any claim.

Ftnchek is an f77 tool. It doesn't understand f95. It isn't useful to
try to figure out exactly what each of the resulting error messages are
about. They can mostky be summarized as "this isn't f77 code", which I
assume you already knew.

I'll do the first one just as an example. Ftncheck doesn't know about
the module statement and keyword, so it assumes that "module
globalknowledgeofletters" is just a long name (identifier) with a blank
in the middle. Blanks in the middle of names were legal in f77 (and in
f90/f995 fixed source form), but were often considered poor practice and
a regulat source of errors.

Fortunately, using f90/f95 features such as modules (and implicit none,
which I didn't see in your code, but I hope was one of the pieces you
cut out) can help catch a lot of the kinds of errors that ftnchek looked
for in f77. Not all, but a lot. That somewhat makes up for ftnchek being
useless on such code; it also isn't as needed.

For example, if you use f90 free source form, the compiler will catch
blanks in names. If you use implicit none, that will catch a lot of the
errors that relate to such blanks, even in fixed source form. If you use
both free source form and implicit none, you've basically got double
protection on that one.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On Sep 21, 4:40=A0pm, Jonas Stein <n...@jonasstein.de> wrote:


> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>
> btw. this minimal example is part of a code, that has the same errormessa=
ges in ftnchek, but f95 compiles without any claim.
>
> Who can help me?
> Thank you,

Unfortunately, no one.  ftnchek is utility for Fortran 77
code with a few extensions for Fortran 90.  Fortran 95 and
above is well outside of ftnchek's capabilities.

If you cannot afford a commercial Fortran lint tool, then
install both g95 and gfortran.  Use -Wall -Wextra and
-Wsurprising to generate warnings.  With gfortran, you
can also use -std=3Df95 (or -std=3Df2003) to restrict the
compiler to a fairly strict interpretation of Fortran 95.

--
steve

steve wrote:
> With gfortran, you
> can also use -std=f95 (or -std=f2003) to restrict the
> compiler to a fairly strict interpretation of Fortran 95.
> 

Just wondering, are there any plans in gfortran (or any other
compiler for that matter) to implement an equivalent of
g95's -ftr15581? From the manual

-ftr15581
Enable the TR15581 allocatable array extensions even in -std=F or
-std=f95 modes.

Given my "day to day" standard is f95+tr15581 this is very useful,

Ian

On 09/22/2010 08:35 AM, Ian Bush wrote:
> Just wondering, are there any plans in gfortran (or any other
> compiler for that matter) to implement an equivalent of
> g95's -ftr15581? From the manual
>
> -ftr15581
> Enable the TR15581 allocatable array extensions even in -std=F or
> -std=f95 modes.
>
> Given my "day to day" standard is f95+tr15581 this is very useful,

For gfortran: I cannot speak for all developers, but I think no one is 
currently working on this or plans to do so any time soon. Though, I do 
not want to rule it out.

Besides: My general impression is that more and more Fortran 95+ 
programs use - conditionally (e.g. configure + preprocessor) or 
unconditionally - certain [cherry-picked] Fortran 2003 features - in 
which case such a flag won't help. Thus, the chance that it gets 
implemented is getting lower.

Actually, I was wondering whether one should add - in gfortran - a flag 
for TR29113 (Further Interoperability of Fortran with C) as this is a 
feature which is likely to be implemented before later (more stable) 
drafts of Fortran 2013 (?) will be available. Ditto for the TR on 
further coarray features.*

Tobias

* Current schedule for the two TRs: 
ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1812.txt . Currently, not 
gfortran developer works on TR29113 (and presumably won't do so before 
2011) but the first MPI vendor already has asked a year ago whether and 
when gfortran will implement it ...

Tobias Burnus wrote:
> On 09/22/2010 08:35 AM, Ian Bush wrote:
>> Just wondering, are there any plans in gfortran (or any other
>> compiler for that matter) to implement an equivalent of
>> g95's -ftr15581? From the manual
>>
>> -ftr15581
>> Enable the TR15581 allocatable array extensions even in -std=F or
>> -std=f95 modes.
>>
>> Given my "day to day" standard is f95+tr15581 this is very useful,
> 
> For gfortran: I cannot speak for all developers, but I think no one is 
> currently working on this or plans to do so any time soon. Though, I do 
> not want to rule it out.
> 
> Besides: My general impression is that more and more Fortran 95+ 
> programs use - conditionally (e.g. configure + preprocessor) or 
> unconditionally - certain [cherry-picked] Fortran 2003 features - in 
> which case such a flag won't help. Thus, the chance that it gets 
> implemented is getting lower.
> 
> Actually, I was wondering whether one should add - in gfortran - a flag 
> for TR29113 (Further Interoperability of Fortran with C) as this is a 
> feature which is likely to be implemented before later (more stable) 
> drafts of Fortran 2013 (?) will be available. 

Yes please! My usage is small, but it has a definite place in what I do,

Ian