https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #17 from Dr. Kevin B. Beard <kevin.b.beard at nasa dot gov> ---
Hi,
Many thanks to Jerry DeLisle [jvdeli...@charter.net]; he made us realize
that an internal record is now not treated the same as an external record! I
didn't think of that.
In the attached example, you see "1,2,3,,,," read from a file with
READ(1,'(2i10)') i,j
DOES still work in gfortran 4.4.7, but
READ(1,'(a)') line
READ(line,'(2i10)') i,j
does NOT. If one parses the string appropriately and reads
it one part of a time, it does work:
READ(line(1:1),'(i10)') i
READ(line(3:3),'(i10)') j
A workaround via an option would be great; better would be to have
internal and external records READ the same way again.
Thanks again for all your help,
Kevin
----------------------------------------------------------
Dr. Kevin B. Beard, Lockheed Martin Corporation
kevin.b.be...@nasa.gov
281-244-8534
room 548C, building 45, NASA Johnson Space Center
US Mail: Kevin B. Beard, bldg 45, mail code Wyle/OPS/45, P.O.Box 58487,
Houston, TX 77258
________________________________________
From: sgk at troutmask dot apl.washington.edu [gcc-bugzi...@gcc.gnu.org]
Sent: Wednesday, November 16, 2016 1:25 PM
To: Beard, Kevin B. (JSC-SD2)[WYLE LABORATORIES, INC.]
Subject: [Bug fortran/78351] comma not terminating READ of formatted input
field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Nov 16, 2016 at 06:36:58PM +0000, kevin.b.beard at nasa dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
>
> --- Comment #13 from Dr. Kevin B. Beard <kevin.b.beard at nasa dot gov> ---
> Hi,
>
> Thanks for looking at this. I'm sorry to say I don't have access
> to the official F77 standards, perhaps you could send me a copy
> of the whole?
google "F77 standard"
https://www.fortran.com/F77_std/rjcnf0001.html
https://gcc.gnu.org/wiki/GFortranStandards
> The section you quoted doesn't seems too exclude the comma-terminated
> behavior I've always seen, and it has been widely used
> by many many programmers throughout the community over the years.
I cited the entire relevant passage. Now, edited to its essences.
13.5.9.1 Integer Editing
The Iw and Iw.m edit descriptors indicate that the field to be
edited occupies w positions.
On input, an Iw.m edit descriptor is treated identically to an
Iw edit descriptor.
In the input field, the character string must be in the form
of an optionally signed integer constant, except for the
interpretation of blanks (13.5.9, item (1)).
In your code, you have
character*80 s
s= '1,2,3,,,,'
READ(s,'(2i10)') i,j
The format request a field width of 10 for 'i'. So, 10 positions
in 's' are '1,2,3,,,, ' (where I had to add a space because
technically 's' does not have 10 positions). A signed integer
constant does not contain 5 commas.
> I've always been told and believed that a comma terminated a
> numeric field;
For list-directed input (i.e., FMT=*), yes, a comma is a
value separator.
> but w/o > access to the standards I can't point to the line that
> says it must.
You won't find a line. I cited the entire relevant text from
Fortran 77 that applies to the above code. You either need to
change the code to
character*80 s
! 12345678901234567890
s= '1 2 '
READ(s,'(2i10)') i,j
where '1' can appear anywhere within the first 10 positions, or
character*80 s
! 12345678901234567890
s= '1,2,3,,,,'
READ(s,*) i,j
> What I'd like to see is that newer gfortran versions support
> its previous (and every other FORTRAN compiler I've tested)
> behavior.
So, no bugs should ever be fixed? Have you filed bug reports
with all the other vendors? I suspect that if you use an
option with those vendors' compiler to request Standard
conformance, you'll find that the code is invalid. If not,
file a bug report with those vendors.
> The flag "-std=legacy" does not restore the previous behavior,
> and I've found no option in the newer gfortrans that does.
That's because no one has implemented the patch to (un)fix gfortran
to handle invalid code. jerryd has indicated that he'll look into
the issue.
I do find it ironic that you refuse to fix broken code,
but expect those that strive to provide a quality tool
like gfortran to break its conformance to the standard.
--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.
=
