This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Is it a bug in gfortran ?
- From: Arjen Markus <arjen dot markus895 at gmail dot com>
- To: Jerry DeLisle <jvdelisle at verizon dot net>
- Cc: Vladimir Nazarov <nazarov at gate dot sinica dot edu dot tw>, fortran at gcc dot gnu dot org
- Date: Wed, 20 May 2009 09:43:19 +0200
- Subject: Re: Is it a bug in gfortran ?
- References: <000901c9d8d5$81cf9b30$a32da8c0@nazarov2> <4A134F07.8090509@verizon.net>
2009/5/20 Jerry DeLisle <jvdelisle@verizon.net>:
> Vladimir Nazarov wrote:
>>
>> Hello,
>> I would expect the following code to print 4.
>> But it prints 101 instead.
>>
>> Is it a bug ?
>> Vladimir.
>> ----------------------------------------------------------
>>
>> character*10 s
>> s='1 2 3'
>> read(s,*,end=1) (x,i=1,100)
>> 1 print *,i
>> end
>>
>>
>>
> I think this is the same as PR32382.
>
> The code that checks for the error condition is outside the implied do loop.
> Front end issue which I have not had time to deal with.
>
I do not think it is an error in the sense that this violates the
standard. Many compilers
exhibit the same behaviour and if I understand the standard's
requirements well, then
the compiler should be able to report the fact that an error or
end-of-file (input) occurred -
not where in the implied do-loop it occurred.
After all, in a statement like:
read(s, *, end=1) x, y, z, t
there is no way to report that only the first three variables were read.
Regards,
Arjen