Re: pr25039 Frontend problem?

[Richard E Maine <Richard dot Maine at nasa dot gov>]

On Nov 25, 2005, at 9:00 PM, Jerry DeLisle wrote:

> Steve Kargl wrote:
> > On Fri, Nov 25, 2005 at 05:38:36PM -0800, Jerry DeLisle wrote:
> > > Could someone take a look at -fdump-tree-original and confirm if 
> > > this is a frontend problem.  I think this is a regression with this 
> > > unprintable chracter showing up in the struct statement.
> > Is "1,1" valid input (where I'm using quotes because space is 
> > important)?
> > The read statement is READ(5,'(2i9)') I1,I2.  This is expecting 2 
> > integers
> > where the width of each integer field is 9 characters.  "1,1" is 3
> > characters.  It's been awhile since I looked at what a comma does
> > in formatted input (I normally do unformatted input).  Does a comma
> > short-circuit a field width?
> Thats what I thought, that the spaces mattered. Well g77 and ifort 
> accept the input and evidently a comma does short-circuit the field 
> width.

The standard says that a comma does *NOT* short-circuit the field width 
in an explicit format. (By the way, I assume that the above reference 
to "unformatted" actually refers to list-directed formatting. Please, 
list-directed is a specific case of formatted input; it is *NOT* 
unformatted. I have helped multiple people fix buggy code caused by 
this misuse of terminology; they open a file with form='unformatted' 
because they intend to use list-directed I/O on it).

I *DESPISE* compilers that short-circuit explicit field widths like 
this. What "ought" to happen (according to my expectations) is that 
hitting a comma in a numeric field should be an error condition that is 
reported via iostat= and err= as appropriate. User code "ought" to be 
able to count on this as a way to detect such thngs. The only way that 
such compilers can even pretend to be standard-conforming is by 
appealing to the fact that the standard says it does not define the set 
of error conditions. Thus, it turns out, user code can never actually 
rely on using iostat= constructively for such purposes. The compilers 
that implement this abomination can claim that the user code was 
non-conforming and thus the compiler is free to do anything with it. 
Have I mentioned how much I hate such compilers? I consider them to be 
squeezing by on a technicality, but failing to implement what I 
consider to be the spirit of the standard on this.

If you feel that you have to implement this abomination, at least make 
it switch controllable.  (And preferably default it to acting like the 
standard would lead a reasonable person to expect.) Please?

I think I have mentioned before that I fear gfortran is going too far 
in the direction of accepting every strange nonstandard feature out 
there. In my personal opinion, that isn't the path to follow to get a 
robust and user-friendly compiler. This particular feature favors the 
arcane over the straightforward interpretation of the standard. Yes, it 
actually makes user codes that assume the straightforward 
interpretation fail. I once had some such codes, but I subsequently had 
to abandon the practice because the codes failed on compilers that 
implemented this particular misfeature.

--
Richard Maine                |  Good judgment comes from experience;
Richard.Maine@nasa.gov       |  experience comes from bad judgment.
                            |        -- Mark Twain