[Patch/fortran] Add documentation section about implemented F2003 features

[Janne Blomqvist]

On Tue, Aug 02, 2005 at 02:39:07PM -0700, Richard E Maine wrote:
> On Aug 2, 2005, at 2:15 PM, Janne Blomqvist wrote:
> 
> >I also removed the mention of eventual support of Fortran 90. IMHO the
> >inability of F95 allocatables to leak memory, as opposed to the F90
> >ones, is sufficient reason alone to actively discourage users from
> >using F90.
> 
> I'm not sure what you mean by that. There is no standard-conforming way 
> for f90 allocatables to leak memory either. The big problem with f90 
> allocatables was that they could get an undefined allocation status in 
> which case it was illegal to ever do anything with them again. 

Um yes, that's what I meant. Unless I have got it completely
backwards, F95 automagically deallocates non-saved allocatables when
they go out of scope. In F90 it is the responsibility of the
programmer to remember the deallocate.

As far as the F90 standard goes, an allocated variable that isn't
explicitly deallocated before it goes out of scope becomes undefined,
and if it is ever accessed again the processor is free to print "42"
and start WWIII? Practically speaking, I guess the usual
implementation of F90 allocatables would imply leaking the memory and
continuing happily, which is what I mean by my comment about leaking
memory. Sorry for not spelling it out in more detail.

[snip]

> 2. If they are touched, then the code wasn't valid f90 and who knows 
> what would have happened to it with f90 compilers. I don't think we 
> need to worry in this context about discouraging users from writing 
> code that is invalid under whatever version of the standard they are 
> trying to write to.

I disagree here. While one can always say that experienced programmers
know what they are doing, I point you at the large number of buffer
overflow errors in C programs written by experts as a
counterpoint. That is not to say that programmers should be protected
from themselves to the point that they cannot accomplish they task at
hand, but in this case I personally can't see a single reason why an
F90 allocatable in the undefined status would be beneficial.

Well, what I'm more worried about is not so experienced
programmers. Say, an inexperienced programmer is ordered by his boss
to write a Fortran program, picks up a Fortran 90 book somewhere,
looks at the gfortran man page and sees that we have a -std=f90
switch, starts programming and at some point forgets to deallocate an
allocatable and later tries to access it again. Well, there we have
WWIII.

Or for another example, a non-programmer gets a bunch of .f90 files
without a Makefile for, say, a simulation program he needs
(unfortunately this scenario isn't too uncommon, AFAIK). So he thinks
that .f90 means the program is F90, looks at the man page and enables
the -std=f90 option. Well, what if the program in fact was F95 and the
programmer hasn't bothered to deallocate as he knows that the compiler
will take care of it (that's what I personally do, for example)? WWIII
again?

With F95 allocatables these problems would never occur. Add to that
that the cost in terms of performance for the extra check (depending
on how the compiler implements it) is IMHO insignificant in any
practical situation. Or in other words, I don't see a justification
why gfortran should go out of its way to help the user shoot himself
in the foot.

> For the same reason, I don't know what you mean by "eventual" support 
> of f90. If you support f95, then you already support f90; nothing 
> additional is needed. (Well, I suppose there might be cases where f90 
> mandates diagnostics for what look slike invalid syntax in f90, but is 
> valid f95, but that's all).

I meant an option -std=f90, which would flag the new F95 features as
illegal, not automatically deallocate non-saved allocatables etc. I
hope I have explained well enough why I think that the F95
allocatables are a good thing and that F90 allocatables should not be
supported, and the other feature differences are really IMHO minor in
the sense that I don't think it will hurt the user if they are there
but the users stick to what's strictly defined in the F90 standard if
that's what the user wants. Ergo, I don't think a -std=f90 option is
justified. Well, there's the F95 deleted features issue, but we
already have -std=legacy for that (perhaps -std=gnu also enables at
least some of them, I don't really remember).

-- 
Janne Blomqvist