Need confirmation PR24459 is NOT-A-BUG

[Jerry DeLisle]

Paul Thomas wrote:
> Jerry,
> 
>> My interpretation is that the names qualifier (1,1) is asking for 
>> exactly one data item.  Providing more is contrary to F95 standard, 
>> less is OK.
> 
> 
> I agree.
> 
>>
>> So gfortran happily fills the request and starts looking for the next 
>> object in the file, which does not exist and so a runtime error 
>> message is given correctly.
>>
> ifort's behaviour is general;  the following also works.
> 
>  integer :: i (4) = (/1, 2, 3, 4/)
>  namelist /nl/ i
>  open (10, status = "scratch")
>  write (10, '(a)') " &NL  i(2) = 3, 2, 1 &END"
>  rewind (10)
>  read(10, nl)
>  close (10)
>  print *, i
>  end
> 
> I would eat space and, if FX's runtime standard checking allows it, peak 
> ahead for a letter. If the next character is a letter, treat the new 
> object, as per the standard, otherwise, if there is available space, go 
> on adding data to the previous object, however it was qualified.
> 
>> I need some consensus on this before I put any more effort on it.
> 
> 
> I would say that it is right on the margin but should be done if there 
> is an easy way to do it - a Sherlock Holmes "one piper".
> 
> However, at very least, clear the PR with the message that gfortran is 
> behaving according to the standard.
> 
> Paul
> 

I understand what you are saying, but the right way to get that result is to use:

" &NL  i(2:) = 3, 2, 1 &END"

I wonder if this is one of those "defacto" standards that we just have to do in 
spite of the real standard?

Regardless, for character type I would have to eat spaces and check for a quote. 
  If there is one, then adjust the array_loop_spec to keep going.

It can be done and I will even take it on, but I want to make sure the gate 
keepers want this.  I will also go back to the bug report and suggest the 
correct work around.

Anyone else please speak up?

Regards,

Jerry