[followup] g77 bug? "I/O recursion" -- very annoying

[Mumit Khan <khan at xraylith dot wisc dot edu>]

I had written earlier regarding libf2c's handling of SIGINT during I/O:
> I just noticed someting that was definitely not present in earlier
> versions of libf2c (eg., in that supplied with 0.5.19.1). If you 
> interrupt a program while it's doing I/O, it acts quite unreasonably. 
> Here's an example:
> 
> ==== 
> % ./g77-io-bug
>  At the following prompt either enter an integer
>   or hit control-c to see what happens
> Enter an integer or Hit Ctrl-C now: Interrupt
> I/O recursion: I/O started while already doing I/O
> apparent state: unit 5 (unnamed)
> last format: list io
> lately reading sequential formatted external IO
> Abort (core dumped)
> ==== 

Well, the problem seems to be Craig's f__init handling. Here's the
sequence of what happens when you interrupt a g77 program while it's
waiting for input (f__init |= 2):
  - SIGINT handler sigindie() gets called
    - sigindie() calls f_exit()
      - f_exit() f_clos() to flush open channels
	- f_clos() checks f__init and yells recursion.

Unless I revert back to netlib libf2c's handling of f__init, I don't see
a reasonably clean way to avoid this problem. 

Would it make sense to reset f__init in sigindie (f__init &= ~2) to
avoid this scenario? Would that open up the possibility of real I/O
recursion?

Regards,
Mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/