Fortran - A bug by any other name, ... (was: Reduce Blanks challenge

Author

A bug by any other name, ... (was: Reduce Blanks challenge

William M. Klein

2005-08-23, 7:00 pm

D.F. posted earlier,

"David Frank" <dave_frank@hotmail.com> wrote in message
news:s0iOe.27$_84.19@newsread1.news.atl.earthlink.net...
> OK, when I was experimenting using my PACK syntax in a test program
> suddenly CVF got unhappy with the identical PACK syntax that was acceptable in
> my strings.f90 file..
> So I am WRONG, acceptance is NOT assured and I have updated my REDUCE_BLANKS
> function in
>
> http://home.earthlink.net/~dave_gemini/strings.f90
>
> accordingly to use PACK ( a(2:), a(2:) /= ' ' .OR. a(1:LEN(LINE)-1) /= '
> '), pad )
>
> This is a CVF bug,
> also noted is removing the -1 from the LEN(LINE) also made it accept the
> statement in my test program.

***

I freely admit that I do not know Fortran, but when he states

" acceptance is NOT assured"

and then goes on to call this a CVF bug, it seems to me (and I certainly could
be wrong about this) that what he is stating is "not assured" is something that
others quoted from the current (possibly even past) Fortran standards as being
something for which there was NO requirement to be "assured".

Can someone who knows Fortran (and the standard) confirm or deny this? If it is
true, then what he is calling a "bug" in the CVF compiler is actually (if
anything) a "bug" in the CVF *documentation* - if and only if - it does not
currently (clearly) document that "results are unpredictable" for such code.

If I am mistaken about whether or not the Fortran Standard *does* "assure
results" for such code, does anyone know the procedure for "reporting" compiler
bugs in CVF and would they let us know what the vendor's response is to this
"bug".

Obviously, if as I suspect (but could be in error) the only "bug" is in the
documentation not making it clear that the source code is "unpredictable"
(and/or invalid) Fortran, then hopefully (but I doubt it) D.F. will stop
posting that he had to "change his code BECAUSE of a bug in the CVF compiler".

--
Bill Klein
wmklein <at> ix.netcom.com

Richard E Maine

2005-08-23, 7:00 pm

In article <XjKOe.114623$j83.56785@fe05.news.easynews.com>,
"William M. Klein" <wmklein@nospam.netcom.com> wrote:

> it seems to me ... that what he is stating is "not assured" is something that
> others quoted from the current (possibly even past) Fortran standards as
> being something for which there was NO requirement to be "assured".
>
> Can someone who knows Fortran (and the standard) confirm or deny this?

1. You are basically correct. The code in question was nonstandard, but
in a way that the standard does not require diagnosis of. It is widely
considered to be highly desirable/useful (even though not required by
the standard) for compilers to have the capability of diagnosing such
things, and indeed most compilers (including CVF, as we have seen) do
have such capability, but it often requires explicit enabling because of
its run-time cost.

2. I do claim to have some small knowledge of the standard (I was the
editor for both f95 and f2003). I typically don't mention that
explicitly because I prefer arguments based on technical merit and
citation rather than based on people and their titles. But I'll make an
exception here to note that I recommend taking *ANYTHING* that DF says
about the Fortran standard with a rather substantial grain of salt.
(Even better, I'd recommend not reading his posts at all because I think
you'll get more bad information that good from them). In the past, he
has been known to explicitly state that he has his own definition of the
term "standard" and that he considers the ISO document to be irrelevant.
In his recent statements I've seen a different line, but I have trouble
keeping track of his current line and mostly I don't care.

Anyway, my message here is that I do not feel it worthwhile to
continually point out the various relationships between DF's statements
and the standard, whether the statements arise from ignorance,
intentional misdirection, matters of possible debate, or even happen to
be completely correct. My usual silence (broken only momentarily) is not
to be considered as agreement.

I will not even guarantee to answer direct questions on the subject. If
you honestly want to know the answer to some question about the Fortran
standard (the ISO one) for reasons other than to debate with DF, your
odds of getting me to respond are *FAR* better if you write it as a
completely independent question, with no reference to DF or to any of
the flamewars that regularly rage around him.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

robin

2005-08-24, 3:57 am

William M. Klein wrote in message ...
>D.F. posted earlier,
>
>"David Frank" <dave_frank@hotmail.com> wrote in message
>news:s0iOe.27$_84.19@newsread1.news.atl.earthlink.net...
in[color=darkred]
REDUCE_BLANKS[color=darkred]
>
> ***
>
>I freely admit that I do not know Fortran, but when he states
>
> " acceptance is NOT assured"
>
>and then goes on to call this a CVF bug, it seems to me (and I certainly could
>be wrong about this) that what he is stating is "not assured" is something that
>others quoted from the current (possibly even past) Fortran standards as being
>something for which there was NO requirement to be "assured".
>
>Can someone who knows Fortran (and the standard) confirm or deny this? If it
is
>true, then what he is calling a "bug" in the CVF compiler is actually (if
>anything) a "bug" in the CVF *documentation* - if and only if - it does not
>currently (clearly) document that "results are unpredictable" for such code.
>
>If I am mistaken about whether or not the Fortran Standard *does* "assure
>results" for such code, does anyone know the procedure for "reporting" compiler
>bugs in CVF and would they let us know what the vendor's response is to this
>"bug".
>
>Obviously, if as I suspect (but could be in error) the only "bug" is in the
>documentation not making it clear that the source code is "unpredictable"
>(and/or invalid) Fortran, then hopefully (but I doubt it) D.F. will stop
>posting that he had to "change his code BECAUSE of a bug in the CVF compiler".

Frank had to change his code because of a bug in his
program (incompatible arrays).
He did not have array bounds checking enabled (he claims
that there is no switch to enable that to be done,
but another Fortran user posted that he doubted that that
claim was correct).

Sponsored Links