At 12 Jul 2002 18:40:42 -0400, Nathan J. Williams wrote:
> cgd@broadcom.com writes:
> > If the standardized definition of abort() changes in that way, I think
> > we should still make the attempt to fclose() (or perform similar
> > operations, e.g. flushing, before closing).
> 
> The argument against this is that in situations where you need to
> abort(), you have detected an inconsistency and need to bail
> out immediately and core dump, without touching any state.

indeed.  However, i think it may be true that people call abort() more
often than they strictly need to (similar to how they don't always use
stderr for their error-ish messages).


> Having detected an inconcistency, there's no reason to believe that
> *any* of your data structures, including stdio streams, aren't also
> corrupt, so trying to flush streams or do other recovery work will
> only hurt you.

Well, saying that it _will_ only hurt you is a bit extreme.  there's
no reason to believe that it won't, except that corruptions of library
data structures are possibly less common.

Certainly, attempting to _change_ the internal state is probably
hazardous (and plus, if you did you'd not accurately be showing the
state at time of abort()).

One might try some (fairly arbitrary ground) like, for each stdout,
stderr:

	* if the output methods are the normal ones, and

	* if there is data in the buffer waiting to be output,

	* then try something which won't itself be fatal but which
          would possibly make the last output available, like
          write()ing the buffered data.

I think the only thing particularly bad about that idea is, the state
of the output files doesn't then necessarily correspond to the state
of the output files as reflected in the core dump's stdio structures.


I think it's probably reasonable to just punt and do the new thing (if
that becomes standard), but i'm just concerned that that might make
things a bit harder for some (admittedly, but not severly) sloppy
programmers.

(Of course, the old behaviour would have to be provided by a versioned
call "forever.")



cgd