`safe' putc (was avoiding stdio)

[brnstnd at stealth.acf.nyu.edu]

In article <22169 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
> In article <25929 at stealth.acf.nyu.edu> brnstnd at stealth.acf.nyu.edu writes:
> >  extern FILE *_mAcVaR_putc_f;
> >  #define safeputc(c,f) ( (_mAcVaR_putc_f = f), putc(c,_mAcVaR_putc_f) )
> >safeputc, like fputc, uses non-local variables, so neither one can be
> >used twice at once safely (e.g., in a signal handler). ...
> 
> But, unlike fputc, safeputc is not safe under the following condition:

Unfair. The stdio documentation doesn't mention any caveat for fputc,
and you're explaining a situation where this problem doesn't happen?

As I claimed, safeputc has the same effect as fputc, unless the stream
is used in a signal handler.

> 	a. You ensure that malloc blocks signals.

How? Without cooperation from the signal handlers you can't hold signals
and release them later.

> 	b. You have a signal handler that opens a file, uses `safeputc',
> 	   then closes the file.
> 	c. Your main program uses `safeputc'.

Okay. To solve this ``problem,'' safeputc must use a local variable.
Expressions can't (in standard C) contain blocks, so without inline
functions this is impossible.

> putc *is* *documented* as not being careful about its second parameter.

It's wonderful that this mistake is documented. It's still a mistake.

---Dan