Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!stealth.acf.nyu.edu!brnstnd
From: brnstnd@stealth.acf.nyu.edu
Newsgroups: comp.lang.c
Subject: Re: `safe' putc (was avoiding stdio)
Message-ID: <670@stealth.acf.nyu.edu>
Date: 7 Feb 90 23:43:50 GMT
References: <10883@attctc.Dallas.TX.US> <21689@mimsy.umd.edu> <25929@stealth.acf.nyu.edu> <22169@mimsy.umd.edu>
Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
Distribution: usa
Organization: IR
Lines: 33

In article <22169@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
> In article <25929@stealth.acf.nyu.edu> brnstnd@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