and we get what we must get, and error
*** C must appear in a type declaration because IMPLICIT NONE has been used
1 ERROR, 1 WARNING [<main program> FTN95/Win32 v7.10.0]
*** Compilation failed

IMPLICIT NONE, designed to get rid of implicit definitions of variables based on their first letter had two additional spurious consequences, positive and negative. The positive one is that compiler now finds static typos in the source at the compile time and issues an error mesage. Negative is that you need to declare every variable. Bad about last one is that if you do that in the module, then when you look at the code you have to jump into distantly placed module to see how specifically you declared everything including each and every index i,j,k...That becomes a hell when you make variables long but differ in few letters. By the time you get back and forth, you forget the variable doing that few times. And I am dead serious! With very large codes that is unacceptable, killing time and certainty and making huge inconvenience. And by the way, the integers and reals are given evils in Fortran, IMPLICIT NONE makes them all same faced, like males and females become of something middle.

I suspect that the absurdness of first example most probably has some strong backing by the Fortran Standard a la "It is the used who has to take care of everything in his own code , not compiler" or "if change that behavior this will break a lot of old codes" etc.

There exist an option in FTN95 to make all WARNINGs to become errors, but that is absolutely not acceptable with large codes, they have megabytes of different kind warnings.

To make all happy i suggest to add the compiler special switch which will oblige compiler to declare an error on every statically undefined variable it finds at compilation time like the C variable above. May be this option exists already hiddenly ?

Then we will get best of all worlds by checking static and dynamic errors (with /undef) forgetting forever annoying error-prone IMPLICIT NONE

Last edited by DanRRight on Tue Jul 21, 2015 7:13 pm; edited 1 time in total

... i suggest to add the compiler special switch which will oblige compiler to declare an error on every statically undefined variable it finds at compilation time like the C variable above. May be this option exists already hiddenly ?

This is already implemented, but hidden from those who do not read the documentation.

Code:

ftn95 /err /set_error_level error 298 <file.f90>

See the help file for details.

The usefulness of static code analysis is going to be limited because the depth of such analysis made by FTN95 (and most compilers) is limited. In the first example code above, the error is easy to detect because there is no assignment to c ("c=" or "read...c") prior to the expression containing c. If the code is a bit more complex, as given below, the compile will fail to detect the error, nor should we expect it to do so in normal usage (to keep compilations going fast). It is a bit too much for the compiler to analyse the code and note that the IF condition will not be satisfied since a = 1.

must be considered to be unsafe, or possibly incomplete, because it has no ELSE, whereas the far less easy to comprehend and reviled arithmetic IF covers all the avenues! With the arithmetic IF, the programmer had to construct the arithmetic test AND consider what to do with all the possible results. Some possible ways of completing the IF include:

(a) ELSE (including sufficient ELSE IFs and possibly a final ELSE)

(b) Initialisation of variable c with the IF doing special cases,
e.g.

Code:

c=2.
if (a > 2) c = 3.

In this construct, the ELSE cases are catered for adjacent to the IF.

(c) Detection of special cases that would crash the program, e.g.

Code:

if (c .eq. 0.) go to 200
b=a/c

This could be done even if the likelihood of getting c=0. was negligible: the compiler writer considers detection of a divide by zero and a tidy close down of the program to be a successful conclusion to proceedings, but the Fortran programmer like me considers it to be a crash, and therefore a fault in the program or its data. At the very least I would want to take the opportunity to allow the user to save their work in progress, AND to give a helpful diagnostic (more helpful than the FTN95 report, which is fine for the programmer). I would normally put everything associated with that at the end of the affected subprogram so it was out of the way of normal logic, which is why I find the equally reviled GO TO to be of more use than to do it within an IF .. THEN .. ELSE .. construct.

Eddie,
What, you don't like this suggestion to make compiler switch to hunt some static undefined variable errors? I do not offer to kill implicit none. Why i posted here? I see no response of Silverfrost in previous discussion 'Attributes of file' in 'General" that the example i posted logged for investigation while few people hinted that it's an error, so i posted this one here in 'Suggestions'. What is left now to discuss is may be to give good name for compiler switch and though this feature will not be commonly accepted among all compilers, it will still hunt you bugs. Did we violate standard with that somehow? Absolutely not.

As to is it an error in my first example above or it isn't? Anyone please try different compilers, let's see how majority of Fortran compiler developers treat the Standard.

Last edited by DanRRight on Wed Jul 22, 2015 12:30 am; edited 2 times in total

I was operating on your 'No more IMPLICIT NONE'. I could be wrong about your intentions here, and I'm happy to be corrected. However, the case for it as elaborated by others fails if you program defensively - although IMPLICIT NONE lovers claim to be doing just that.

I can't agree as my world has /implicit_none.
This discussion must be what happens when worlds collide !

Unfortunately, at present I can't /undef or even /check, as I need /alloc_global to overcome checking with lots of allocate.
I appears that I am going too close to 2gb limit when /check is being included.

I would make a suggestion that something like /alloc_global be implemented, although I would like to know what this means for using SDBG.

Just like /implicit_none, I am also convinced on using ALLOCATE and defining these arrays in MODULES, which overcomes some of the problems identified in TR-15581.

This approach works well. About a year ago, I wrote a program that interrogates a personal finance database I have. I wrote it with no array size limits. The design approach was to do multi-pass reading of the database to first identify the size of data structures, then allocate arrays for their size and then re-read the information into these arrays; continuing with the data recovery. The data base has 3 types of records; companies, prices and adjustments.
My database typically has about 200 company records, but on recent use, there was a failure with data input to the finance package and this number exploded to 5000. My program was able to read the database and report the problems. If I had written this using COMMON arrays, I probably would have allowed for 500 companies and the program would have failed, giving a cryptic error report that would have caused me to go back and debug the program when I had other problems to address with the finance package.
It was pleasing that my program design approach had worked so well.

How can you do no size limit with 32bit compiler? Did you use some other 64bit compiler? Or actual numberof byts in memory is less then 2-3 GB? What is the size of database you need to load?

Just one variant of mine is ~20-100GB, i can barely load tiny part of it at a time, let alone to use any allocatables conflicting with stack when the size in memory approaches 1-2 GB. Simple tests with one allocatable array may show up to 4GB is loaded (2 in allocatable and 2 into stack) but in real task with few arrays this breaks into freezes with no ends possible to find. The solution is to wait for 64bits

And what is the size ( lines of code) of your fortran text? If it is not very large then implicit none works. If not, in my experience in the 100-200k lines, then it is barely useful. At some size you start to feel that the difficulties to add something increase exponentially. And there you will start appreciating /undef like no other switch. That size estimation above may depend on your writing skills in regular human languages as there exist some people who can write the whole scientific articles or novels from the beginning to the end with no single typo or change and some rewrite 7 (Tolstoj) or 777 (me) timers. I speculate those unique writers would be good programmers when size grow.

Right now this bewitched at its almost useless 32bits compiler with its totally absurd errors is trying to degrade me to the state of neanderthal. No single line of progress today.

Certainly 32 bit or 64 bit implies limits to the data size. The database I am using is a byte addressable file with 4-byte addresses, so is limited to 2gb. ALLOCATE can be very helpful for memory limits, as you can define array sizes to be minimal for the problem you are solving, then release the memory when no longer required.

I probably mentioned previously another terrain model I have for a 75km long channel, which I divide into virtual pages of 1000m x 1000m points. there are 75 x 75 virtual pages but only about 200 in use. The virtual address of (IX, IY) to nearest metre is converted to (Page, JX, JY). I have found this to work well with 32-bit. I process the info, based on active pages only, which reduces the workload substantially.

The main program I am trying to use /check on is about 40k lines and 500 routines. It has many sub projects which makes it easier to work with. I have been working on it for 30 years.