Re: unsafe functions from signal handler

bill pursell wrote: 
I came upon the following code yesterday in a signal handler:

fflush(stderr);
fprintf(stderr, "...%d\n", signal);
fflush(stderr);
/* snip */
exit(-1);

This brought to mind several questions:

1.  fprintf is not a safe function, so it is a bad idea to
call it from within a signal handler.  However, it strikes
me that the only problem with it is that the writes to stderr
will be interleaved and munged a bit.  Is there a more
substantial problem?  Also, does it matter if the signal

If the main program is in the middle of updating the fields
in the FILE, and a signal occurse, reading/writing half garbled
members havoc might follow (there are various X_unlocked functions)

FILE operations are normally locked though on posixishy systems with
pthreads (yes - even if your program doesn't use threads - just as with malloc :-) so you risk deadlocking your program.
.

Relevant Pages

  • Re: unsafe functions from signal handler
    ... fprintf is not a safe function, so it is a bad idea to ... FILE operations are normally locked though on posixishy systems with ... malloc :-) so you risk deadlocking your program. ... but the second signal causes an abort) ...
    (comp.os.linux.development.apps)
  • Re: Inlining S-Functions
    ... Function that performs file operations using fprintf? ... inlining requires to write a .tlc-file, which is ...
    (comp.soft-sys.matlab)