Standard question: I/O - reading an integer from a too short string
Tobias Burnus
Shall it print "0" or shall it abort with an end-of-record error?
Naively I had expected an EOR (or EOF), but with all but one compiler
there is no reading error but a "0" is printed.
What does the standard demand (and in the case both is acceptable by the
standard, what is the personally prefered result)?
I looked into the standard, but I could seemingly not spot the right place.
---------------------------------
implicit none
character(len=5) :: str
integer :: a
str = ''
a = 5
read(str,'(5x,i1)') a
print *, a
end
---------------------------------
(The zero printing is due to: "10.6.1 Numeric editing": "On Input [...]
A field containing only blanks is considered to be zero.")
Thanks,
Tobias
glen herrmannsfeldt
> What is the supposed result when one runs the following program?
> Shall it print "0" or shall it abort with an end-of-record error?
> Naively I had expected an EOR (or EOF), but with all but one
> compiler there is no reading error but a "0" is printed.
> What does the standard demand (and in the case both is
> acceptable by the standard, what is the personally
> prefered result)?
As far as I understand it, at least for external I/O, it has been
allowed over the years either EOR or to consider the record
extended with blanks. Part of the reason for the confusion is
from the transition from fixed length records (cards) to variable
length (CRLF terminated lines). With card input, records were
always 80 characters long, even if there were no printable
characters.
> I looked into the standard, but I could seemingly not spot
> the right place.
> ---------------------------------
> implicit none
> character(len=5) :: str
> integer :: a
> str = ''
> a = 5
> read(str,'(5x,i1)') a
> print *, a
> end
> ---------------------------------
> (The zero printing is due to: "10.6.1 Numeric editing": "On Input [...]
> A field containing only blanks is considered to be zero.")
-- glen
Dick Hendrickson
> What is the supposed result when one runs the following program?
> Shall it print "0" or shall it abort with an end-of-record error?
>
> Naively I had expected an EOR (or EOF), but with all but one compiler
> there is no reading error but a "0" is printed.
>
> What does the standard demand (and in the case both is acceptable by the
> standard, what is the personally prefered result)?
>
> I looked into the standard, but I could seemingly not spot the right place.
It's scattered around, but the PAD= is the thing you want.
In internal I/O it says it acts as if there were an OPEN
without a PAD= specifier. In the OPEN section it says the
default for no PAD= is YES. In 9.5.3.4.2 it finally says
"During advancing input when the pad mode has the value YES,
blank characters are supplied by the processor if the input
list and format specification require more characters from the record
than the record contains."
So, the processor should supply extra blanks as needed.
Dick hendrickson
Richard Maine
> Tobias Burnus wrote:
> > What is the supposed result when one runs the following program?
> > Shall it print "0" or shall it abort with an end-of-record error?
> >
> > Naively I had expected an EOR (or EOF), but with all but one compiler
> > there is no reading error but a "0" is printed.
...
> It's scattered around, but the PAD= is the thing you want.
> In internal I/O it says it acts as if there were an OPEN
> without a PAD= specifier....
> So, the processor should supply extra blanks as needed.
DIck has the basic analysis here. The one thing I'd add is that this
area has been tightened up over the years. I'd have to go dig to find
the exact relevant versions of the standard, but the business about
internal I/O acting as if there were an OPEN was not there in all
versions.
I'm sure (fairly :-)) that this stuff is all straightened out by f2003,
which is probably what Dick is citing. I am also sure that it was not
specified in f77. I got bit by some related things in f77. In my case,
it was the BLANK specifier instead of PAD, but it was a simillar issue
of specifying how it worked for internal I/O. F77 completely failed to
state. My code failed with one compiler because I had assumed that the
default for PAD applied if PAD wasn't specified. It turns out that the
relevant material was all under the OPEN statement and did not apply to
any case where there wasn't an OPEN statement; the standard left those
cases unspecified and compilers varied in how they treated them.
I recall that, somewhere between f90/f95/f2003, there were at least two
revisions that tightened up this kind of thing. One revision specified
some cases, but missed others. By f2003, I'm fairly sure that things are
stated generally enough that all cases are covered. For f90 and f95, I'd
have to go digging to find exactly what cases are covered and what ones
aren't. I'm thinking it was something like that one revision hit
internal I/O, but forgot that the same question comes up for
preconnected units and the * files.
The code shown by the OP requires at least f90 (for several reasons, one
perhaps less than obvious at first glance). But it is at least possible
that the one compiler that did other than return a zero might still be
conforming to f90; I'd need to check more carefully.
EOR should not be a possibility in any case. That applies only to
nonadvancing reads. And EOF would be wrong as well. For versions of the
standard prior to when PAD got adequately specified here, ERR would be
more appropriate... except that the standard doesn't specify the set of
I/O error conditions, so you couldn't count on that either.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
glen herrmannsfeldt
> Dick Hendrickson <dick.hen...@att.net> wrote:
>> Tobias Burnus wrote:
>> > What is the supposed result when one runs the following program?
>> > Shall it print "0" or shall it abort with an end-of-record error?
>> > Naively I had expected an EOR (or EOF), but with all but one compiler
>> > there is no reading error but a "0" is printed.
>> It's scattered around, but the PAD= is the thing you want.
>> In internal I/O it says it acts as if there were an OPEN
>> without a PAD= specifier....
>> So, the processor should supply extra blanks as needed.
> DIck has the basic analysis here. The one thing I'd add is that this
> area has been tightened up over the years. I'd have to go dig to find
> the exact relevant versions of the standard, but the business about
> internal I/O acting as if there were an OPEN was not there in all
> versions.
So, as of Fortran 2003 it is required to pad with blanks.
For some older versions that requirement wasn't there.
I do remember end of record errors from OS/360 Fortran, reading
(or writing) fixed length records (often LRECL=80 for input,
and LRECL=133 for output). The DEC Fortran 66 compilers pretty
much had to pad, as programs would expect to read an input
record with a format like 80A1, and users would not be exprected
to add enough blanks to reach 80. No internal I/O in Fortran 66,
but DEC supplied ENCODE/DECODE for it. I don't remember if they
did padding for those.
> I'm sure (fairly :-)) that this stuff is all straightened out by f2003,
> which is probably what Dick is citing. I am also sure that it was not
> specified in f77. I got bit by some related things in f77.
(snip)
> I recall that, somewhere between f90/f95/f2003, there were at least two
> revisions that tightened up this kind of thing. One revision specified
> some cases, but missed others. By f2003, I'm fairly sure that things are
> stated generally enough that all cases are covered. For f90 and f95, I'd
> have to go digging to find exactly what cases are covered and what ones
> aren't. I'm thinking it was something like that one revision hit
> internal I/O, but forgot that the same question comes up for
> preconnected units and the * files.
> The code shown by the OP requires at least f90 (for several reasons, one
> perhaps less than obvious at first glance). But it is at least possible
> that the one compiler that did other than return a zero might still be
> conforming to f90; I'd need to check more carefully.
But if not, other than the reasons you indicate that the code
requires F90, an F77 implementation could generate an error?
> EOR should not be a possibility in any case. That applies only to
> nonadvancing reads. And EOF would be wrong as well. For versions of the
> standard prior to when PAD got adequately specified here, ERR would be
> more appropriate... except that the standard doesn't specify the set of
> I/O error conditions, so you couldn't count on that either.
At least in older versions of the standard you can get an end of
record error for formatted and/or unformatted, reading (or writing)
more than the specified record length.
-- glen
nm...@cam.ac.uk
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>So, as of Fortran 2003 it is required to pad with blanks.
>For some older versions that requirement wasn't there.
As of Fortran 90, I believe.
>I do remember end of record errors from OS/360 Fortran, reading
>(or writing) fixed length records (often LRECL=80 for input,
>and LRECL=133 for output). The DEC Fortran 66 compilers pretty
>much had to pad, as programs would expect to read an input
>record with a format like 80A1, and users would not be exprected
>to add enough blanks to reach 80. No internal I/O in Fortran 66,
>but DEC supplied ENCODE/DECODE for it. I don't remember if they
>did padding for those.
That is so. It was one of the many reasons that porting VAX code
to IBM was murder. Our default format for MVS was VB, so we had
trouble, too.
Regards,
Nick Maclaren.
Richard Maine
> Richard Maine <nos...@see.signature> wrote:
> > The code shown by the OP requires at least f90 (for several reasons, one
> > perhaps less than obvious at first glance). But it is at least possible
> > that the one compiler that did other than return a zero might still be
> > conforming to f90; I'd need to check more carefully.
>
> But if not, other than the reasons you indicate that the code
> requires F90, an F77 implementation could generate an error?
Yes.
> > EOR should not be a possibility in any case. That applies only to
> > nonadvancing reads. And EOF would be wrong as well. For versions of the
> > standard prior to when PAD got adequately specified here, ERR would be
> > more appropriate... except that the standard doesn't specify the set of
> > I/O error conditions, so you couldn't count on that either.
>
> At least in older versions of the standard you can get an end of
> record error for formatted and/or unformatted, reading (or writing)
> more than the specified record length.
Sorry, but no, that's just not so. As I said, EOR applies only to
non-advancing reads. That is true in every version of the standard that
has had an EOR. If you are talking about some nonstandard extension, or
perhaps about some >0 value of the iostat return (which would be an
error return) that's a different matter, but it has nothing to do with
any version of the Fortran standard.
glen herrmannsfeldt
> In article <gt4vq9$1cv$1...@naig.caltech.edu>,
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>>So, as of Fortran 2003 it is required to pad with blanks.
>>For some older versions that requirement wasn't there.
> As of Fortran 90, I believe.
>>I do remember end of record errors from OS/360 Fortran, reading
>>(or writing) fixed length records (often LRECL=80 for input,
>>and LRECL=133 for output).
(snip)
> That is so. It was one of the many reasons that porting VAX code
> to IBM was murder. Our default format for MVS was VB, so we had
> trouble, too.
Did you ever use FIO999? That is how I used to do internal I/O
in the OS/360 days. A call to FIO999 would patch the Fortran
library routines (statically linked) such that calls to a
specified unit, often 999, would go to a supplied array instead
of to an actual I/O device. You supplied the unit, the array,
the record length, and the number of records. Not so portable,
but it did work.
-- glen
glen herrmannsfeldt
(snip, I wrote)
>> At least in older versions of the standard you can get an end of
>> record error for formatted and/or unformatted, reading (or writing)
>> more than the specified record length.
> Sorry, but no, that's just not so. As I said, EOR applies only to
> non-advancing reads. That is true in every version of the standard that
> has had an EOR. If you are talking about some nonstandard extension, or
> perhaps about some >0 value of the iostat return (which would be an
> error return) that's a different matter, but it has nothing to do with
> any version of the Fortran standard.
What do you call the error that happens when you read more
than was written to a record in an unformatted file? Most systems,
even if the standard doesn't, will call that an end of record error,
and abbreviate it EOR.
I agree that it isn't well described in the standard, but
it does (and did) happen.
-- glen
nm...@cam.ac.uk
No, but I did comparable hacking :-) I am a machine code hacker from
way back, so usually find it quicker and more reliable to do my own
hacking than rely on someone else's.
Regards,
Nick Maclaren.
Richard Maine
Sure it does, but that is not the end-of-record condition described in
the standard and is thus completely unrelated to the discussion. That
would be an error condition. If you want to use the term "end-of-record"
to describe that particular error condition, then fine, but you need to
qualify it as being an error condition. You can't just take a term from
the standard, use it in a context about the standard (you even said "in
older versions of the standard") and then expect people to understand
that you didn't actually mean the term in the standard.
That reminds me a little bit of a phase my daughter went through when
"nothing she said was ever wrong" because she had her own language in
which all the words meant something different and whatever she said was
correct in her language. :-) No, I'm not saying that you have the
"nothing I say is ever wrong" part; posters with that attitude tend to
be in my kill file (and you obviously aren't). I'm just noting the use
of a term to mean something other than what the standard says it means.
The standard itself even addresses general terminology issues like that.
Somewhere way up front, it says that terms are often given a specific
technical meaning in the standard and when so, that meaning is to be
used instead of some other general English meaning for the same term.
If you tell someone that an EOR condition will result from something,
they are going to be perfecty justified in testing for it with an EOR=,
which isn't going to work if you mean an error condition. And in the
case at hand, where the OP asks whether his code could generate an EOR,
the correct answer is no.