pr25039 Frontend problem?

[Jerry DeLisle]

Richard E Maine wrote:
> 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.
> 
Wow, thanks for clarifying that.  I do have a patch in review that implements 
this abomination.  And I agree with you mostly (99%).  It has been frustrating 
me lately because at least two bugs we have reported are of this nature.  The 
first one I suggested to the user to use proper array triplet qualifiers to 
solve his namelist problem.  He was happy to do that.

On pr25039 we are giving an error now.  I could set it up to give a clearer 
error, that commas are not allowed in numeric input strings and then enable the 
abomination for -std=legacy.

Anyone (everyone?) agreeable to what I propose here?

--Jerry