Re: Ada vs Fortran for scientific applications

[Gordon Sande <g.sande@worldnet.att.net>]

On 2006-05-25 09:09:59 -0300, "Dr. Adrian Wrigley" 
<amtw@linuxchip.demon.co.uk.uk.uk> said:

> On Wed, 24 May 2006 23:04:03 -0700, Richard Maine wrote:
> 
>> Nasser Abbasi <nma@12000.org> wrote:
>> 
>>> I just did this simple test, declare an array and go overbound and see if we
>>> get a run-time error:
>> ...
>>> $ g95 f.f90
>> ...
>>> $   <------------------- NO runtime ERROR
>> 
>> This part of the thread has started drifting away from relevance to much
>> of anything, but that particular sample is just drifting yet further. It
>> illustrates neither much about subscript bounds rules being part of the
>> language nor about bounds checking being part of the language, which
>> were the two topics mentioned earlier in the subthread.
>> 
>> Instead, the example illustrates only that g95 does not have the bounds
>> check option enabled by default, which is yet a third question (and one
>> mentioned in more generality earlier).
>> 
>> As with most compilers, g95 does have a bounds check option; it just
>> isn't enabled by default. Compiling your same example, but asking for
>> bounds checking, gets it. In particular, compiling and running your
>> example code on my Mac here with
>> 
>> g95 -fbounds-check clf.f90
>> ./a.out
>> 
>> Gives me:
>> 
>> At line 4 of file clf.f90
>> Traceback: not available, compile with -ftrace=frame or -ftrace=full
>> Fortran runtime error: Array element out of bounds: 11 in (1:10), dim=1
>> 
>> which is, in fact, more detailed than the message you showed from gnat.
>> (Turning on the trace options gets rid of the message about not having
>> one, but it is trivial and adds nothing else useful for this example.)
> 
> Bounds checking code is not needed if it can be proved never
> to fail.  Sometimes the compiler can do that.  Sometimes the
> programmer can do that, even if the compiler can't.
> This is why the *source code* should be able to disable and re-enable
> checks with fine granularity.  Programmers can comment the code
> as to why checks are unnecessary and disable them.  This fine-grain
> control over checking needs to be standardized across compilers,
> otherwise source files become non-portable.
> (note: IIRC, the Ariane 5 launch failure was linked to disabling a
> range check after careful analysis... of Ariane 4 trajectory)
> 
> A couple of questions about Fortran:
> Are bounds check failures trappable in a standard way so the
>    program can continue?
> Can it be controlled on a finer grain than per compilation?

I am a big fan of subscript checking and undefined variable checking.
I have found that all of the errors that these aids have found have been
in parts of my programs that I believed to be free of such errors
because I had looked hard at them some time before. Either I had
not done a good job of looking or the assumptions underlying the look
had changed.

That seems to be the nature of the beast.

I can avoid (usually!) the trival bugs. I like getting help once the
bug is not trivial. (Maybe that is a definition of trivial.)

Fine grained control would have been of no use, and in fact harmful,
if I had tried to use it. My take is it makes a great checklist feature
that may help get past "desired feature checklists" but is otherwise
not of any real benefit. The check is great but fine grained control
is not.

> Do user defined numerical types have restricted bounds too?

That is a Pascal-like feature that I miss in Fortran. So I do my own
checking. Because of my problem domain I have to be proactive in checking
parameter values on entry to new procedures even if the invocation is
from one that has already checked. The buzz word is programming by contract
if I have read the programming fashion of the day rags.

How many Ada systems can match the undefined variable checking of the
old WatFor or the current Salford CheckMate or the Lahey/Fujitsu
global checking? It seems to be a thing associated with places that
run student cafteria computing on mainframes. Not much used anymore.
There was a similar student checkout PL/I from Cornell if I recall
correctly.

> The adverse consequences of exceeding bounds can be seen to
> outweigh the (usually) modest costs in code size and performance that
> even mature code should ship with checks enabled, IMO.
> Compilers generally should be shipped with the 'failsafe'
> options on by default.