"scratch" file bug in g77/egcs1.1b

[Toon Moene]

>  I would have said something similar to Toon, but this
>  has clearly changed in f90/95 and libf2c should be
>  compatible.  Thank you for the reference to the standard
>  -- that's what we like to see!

I'm surprised you think it's a f90/95 vs f77 issue.  Just in case  
I'll quote the draft Standard (Oct '97) on

1.5.2 FORTRAN 77 compatibility [Note the upper casing]

Except as noted in this section, the Fortran 95 Standard is an  
upward compatible extension to the earlier Fortran International  
Standard, ISO 1539:1980, informally referred to as FORTRAN 77.
...
The following FORTRAN 77 features have different interpretations in  
the Fortran 95 Standard:

1. FORTRAN 77 permitted a processor to supply more precision derived
   from a real constant than can be represented in a real datum when
   the constant is used to initialise a data object of type double
   precision real in a DATA statement.  The Fortran 95 Standard does
   not permit a processor this option.

2. If a named variable that was not in a common block was initialised
   in a DATA statement and did not have the SAVE attribute specified,
   FORTRAN 77 left its SAVE attribute processor dependent.  The
   Fortran 95 Standard specifies (5.2.10) that this named variable
   has the SAVE attribute.

3. FORTRAN 77 required that the number of characters required by the
   input list was to be less than or equal to the number of
   characters in the recorddureing formatted input.  The Fortran 95
   Standard specifies (9.4.4.4.2) that the input record is logically
   padded with blanks if there are not enough characters in the
   record, unless the PAD= specifier with the value 'NO' is specified
   in an appropriate OPEN statement.

4. The Fortran 95 Standard has more intrinsic functions than did
   FORTRAN 77 and adds a few intrinsic subroutines.  Therefore, a
   standard-conforming FORTRAN 77 program may have a different
   interpretation under the Fortran 95 Standard if it invokes an
   external procedure having the same name as one of the new
   standard intrinsic procedures, unless that procedure is specified
   in an EXTERNAL statement as recommended for nonintrinsic functions
   in appendix B of the FORTRAN 77 standard.

5. A value of 0 for a list item in a formatted output statement will
   be formatted in a different form for some G edit descriptors.  In
   addition, the Fortran 95 standard specifies how rounding of values
   will affect the output field form, but FORTRAN 77 did not address
   this issue:  therefore, some FORTRAN 77 processors may produce a
   different output form than Fortran 95 processors for certain
   combinations of values and G edit descriptors.

6. If the processor can distinguish between positive and negative
   real zero, the behaviour of the SIGN intrinsic function when the
   second argument is negative real zero is changed by this standard.

[ End-of-quote ]

Note:  No mention of REWIND or ENDFILE.

>  I can see where things have changed -- apparently due to
>  syncing with the Netlib version -- and will try to sort
>  it out; some of the code there is mine.

Great !  I wouldn't have a clue where to begin ...

Thanks,
Toon.

For those of you using Modern Computer Languages:  "Processor" in  
the various Fortran Standards has the following meaning:

"The combination of a computing system and the mechanism by which  
programs are transformed for use on that computing system is called  
a <B>processor</B> in this standard."