Which f77 compiler is correct (Sun, Linux)? 
Author Message
 Which f77 compiler is correct (Sun, Linux)?

Hi,

I get a curious input behavior with 3 Linux compilers (g77, f2c, pgf77) on a
PIII
but an as expected behavior with the Sun Solaris f77 on a Sparc Ultra:

All the compilations have no option flags.

Terminal input test program : it tests the effect of end-of-file (^D) at input:
--------------
      REAL t
c
 10   t = 0. ! Force the value of t to illustrate the anomalous results on Linux
      READ (*,*,ERR=20,END=30) t
      PRINT *, t, ' read'
      GOTO 10
c
 20   PRINT *, 'ERR detected'
      GOTO 10
c
 30   PRINT *, 'END detected'
      GOTO 10
c
      END
--------------

Sun's f77 result (the ^D is actually not printed on screen):
-----

Quote:
> a.out

1
     1.00000 read
a
 ERR detected
^D
 END detected
^C
*** TERMINATING  a.out
*** Received signal 2 SIGINT
-----

Linux's compilers anomalous results:
-----
$ a.out
1
  1. read
a
 ERR detected
^D
 END detected
 END detected
 END detected
 END detected
 END detected
 END detected
 END detected
... (infinite loop)

-----

It is as if the ^D remains in the input buffer and is not cleared,
yet t is reset in the program before the next read statement.
Clearly the read statement is wrongly behaving.
Any idea for a workaround because I need a Linux executable version?

        Dan



Wed, 18 Jun 1902 08:00:00 GMT  
 Which f77 compiler is correct (Sun, Linux)?
On Fri, 28 Apr 2000 13:25:01 +0200, Pfenniger Daniel

Quote:

>I get a curious input behavior with 3 Linux compilers (g77, f2c, pgf77) on a
>PIII
>but an as expected behavior with the Sun Solaris f77 on a Sparc Ultra:

>All the compilations have no option flags.
[snip]

>It is as if the ^D remains in the input buffer and is not cleared,
>yet t is reset in the program before the next read statement.
>Clearly the read statement is wrongly behaving.
>Any idea for a workaround because I need a Linux executable version?

Both compilers are correct.  Your program is incorrect.

When the third READ encounters the ^D, it is treated as an "endfile
record" and an end-of-file condition exists.  According to the
standard, the file is then positioned "after the endfile record".   It
is then not allowed for a program to initiate a READ when the file is
positioned after an endfile record.  If your program does so, the
results are not defined by the standard.

A possible solution is to do a REWIND or a BACKSPACE, or to close and
re-open the unit (you'll need to use a numbered unit, typically 5 but
that's not guaranteed.) Offhand, I'm not sure how various
implementations would react to a REWIND or BACKSPACE of a unit
connected to a terminal and it may not be possible to reposition the
file.  In this case, you would need to modify your program to not
expect to continue reading after an end-of-file condition.

fortran Engineering
Compaq Computer Corporation, Nashua NH

Compaq Fortran web site: http://www.compaq.com/fortran



Wed, 18 Jun 1902 08:00:00 GMT  
 Which f77 compiler is correct (Sun, Linux)?


Quote:
>Hi,

>I get a curious input behavior with 3 Linux compilers (g77, f2c, pgf77) on a
>PIII
>but an as expected behavior with the Sun Solaris f77 on a Sparc Ultra:

>All the compilations have no option flags.

>Terminal input test program : it tests the effect of end-of-file (^D) at input:
>--------------
>      REAL t
>c
> 10   t = 0. ! Force the value of t to illustrate the anomalous results on Linux
>      READ (*,*,ERR=20,END=30) t
>      PRINT *, t, ' read'
>      GOTO 10
>c
> 20   PRINT *, 'ERR detected'
>      GOTO 10
>c
> 30   PRINT *, 'END detected'
>      GOTO 10
>c
>      END
>--------------

>Sun's f77 result (the ^D is actually not printed on screen):
>-----
>> a.out
>1
>     1.00000 read
>a
> ERR detected
>^D
> END detected
>^C
>*** TERMINATING  a.out
>*** Received signal 2 SIGINT
>-----

>Linux's compilers anomalous results:
>-----
>$ a.out
>1
>  1. read
>a
> ERR detected
>^D
> END detected
> END detected
> END detected
> END detected
> END detected
> END detected
> END detected
>... (infinite loop)

>-----

>It is as if the ^D remains in the input buffer and is not cleared,
>yet t is reset in the program before the next read statement.

>Clearly the read statement is wrongly behaving.
>Any idea for a workaround because I need a Linux executable version?

FWIW I prefer the g77 way of doing it, but neither is wrong.  

OTOH, a program that depends on one behaviour rather than the other IS
wrong.  Why do you expect to be able to read beyond the end of file?

--

Polyhedron Software Ltd.        
Programs for Programmers - QA, Compilers, Graphics

************ Visit our Web site on http://www.polyhedron.co.uk/ ************



Wed, 18 Jun 1902 08:00:00 GMT  
 Which f77 compiler is correct (Sun, Linux)?

Thanks for the explanation.  I was light-years away of thinking about
keyboard in terms of file. I understand perfectly that for real paper
or magnetic tapes, or disk files these rules make sense.
But since obviously the policy for keyboard input is not included in
the standard, the result, as the different compilers show, is not defined
and implementation dependent.  

Now I would say that to consider keyboard input as identical to
a *file* on which I may use a *rewind* statement reveals a rather
tortuous way of dealing with common words.  If the result is
implementation dependent one should admit that Sun's choice provides
at least a better and more robust support for keyboard input that g77.  
The g77 choice means that any unwillingly typed ^D is going to mess the
subsequent keyboard input.  ( I tried to close and open, backspace
and rewind  unit 5 without being able to restore the initial input state).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 Geneva Observatory, University of Geneva | tel: +41 (22) 755 2611
 CH-1290 Sauverny, Switzerland            | fax: +41 (22) 755 3983
__________________________________________________________________________



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. correct behaviour of SUN f90 compiler/linker?

2. I am looking for a Mac f77 compiler - for free of course :)

3. Array sizes on Sun f77 compiler

4. F90 Sun compilers [Was: Migration from F77]

5. Problem with Suns F77 compiler

6. Sun F77 compiler with Vax binary file Query

7. MOD intrinsic with the sun f77 compiler

8. Write to stderr: How? (Sun f77 compiler)

9. static storage compiler switch for Sun f77?

10. Sun F77 compiler

11. "-r8" option on Sun F77 compiler

12. Strange problem with Sun-f77 compiler.

 

 
Powered by phpBB® Forum Software