This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: end and err labels not used in g77 during internal files read


Luc Maisonobe wrote:

> We have encountered a strange behaviour of g77 while reading internale
> files (character arrays). The END= and ERR= specifiers seem to be
> ignored. The following program shows this behaviour. We intend the first
> read to succeed and the second one to fail because the last expected
> field is missing. However when I run this on either a linux or a Solaris
> host, I get this output :
> 
>  date 2001 03 01 10 44 03 999        has been successfully read
>  date 2001 03 01 10 44 03            has been successfully read
> 
> One should note that several other compilers have the same strange
> behaviour. The problem was discovered by a program failing here when
> compiled with SUN forte 6.1 compiler on solaris. I once suspected that
> such specifiers were not available on internal files and checked the
> ISO/IEC 1539 norm which states that the end-of-file condition is
> triggered "when an attempt is made to read a record beyond the end of an
> internal file".

Note that this last sentence refers to "record beyond the end of an
internal file".

If you have just one READ statement that reads one record, as yours
does, it will always succeed on a character variable - because that
comprises the single record needed.

The fact that the record is not `complete' has nothing to do with that -
it also won't invoke the ERR= branch, because (quoting the Fortran 95
Standard, emphasis mine):

"During advancing input [i.e. without ADVANCE='NO'] from a file whose
PAD= specifier has the value YES, *or during input from an internal
file*, blank characters are supplied by the processor if the input list
and format specification require more characters from the record than
the record contains."

Perhaps you could ask Sun for their reasoning behind their forte 6.1
compiler behaving as it does.

Hope this helps,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]