https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #11 from Khang H. Nguyen ---
That is cool with me if you think it that way.
But I don't think you would be very happy parsing " 123 4" and still get the
same result as "1234". Or if you were to give it a blank string and get 0 where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #9 from Khang H. Nguyen ---
No, no, you got me wrong, it is not a tutorial. You got it wrong. I just see so
much insecure with the statement read, of which I think it more like a
procedure. That is why I am trying to report the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #6 from Khang H. Nguyen ---
Sorry, if I am wasting your time.
I just have an addition to add to the above.
If you use formatting. For example, in a case like this below, it will not give
a correct value, as now leading spaces will b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #5 from Khang H. Nguyen ---
> program foo
> integer i
> read(*,*) i
> read(*,'(I4)') i
> end program foo
>
> % gfcx -o z a.f90
> % ./z
> % ./z
> 12 b
> 12 b
> At line 4 of file a.f90 (unit = 5, file = 'stdin')
> Fortran runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #3 from Khang H. Nguyen ---
Sorry, I just have one more quick question.
Bug 1:
Nonetheless, for read(), I was just wondering, if you read from a list input
then it should be like that.
However, if it is just a raw string and it act
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #2 from Khang H. Nguyen ---
okay, thank you for the information, I did not know that.
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: kevin at fai dot host
Target Milestone: ---
For this bug I report, I report two bugs. One could be a potential bug while
the other should for certainly be a bug. These bugs affect both
