Date: Sat, 18 Nov 2000 21:18:31 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: dj AT delorie DOT com
Message-Id: <7263-Sat18Nov2000211830+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: djgpp-workers AT delorie DOT com
In-reply-to: <200011181818.NAA03898@envy.delorie.com> (message from DJ Delorie
	on Sat, 18 Nov 2000 13:18:56 -0500)
Subject: Re: snprintf() diff
References: <200011132023 DOT PAA04930 AT qnx DOT com> <3A1328A7 DOT C9866232 AT bigfoot DOT com> <200011160105 DOT UAA01282 AT envy DOT delorie DOT com> <8011-Sat18Nov2000100818+0200-eliz AT is DOT elta DOT co DOT il> <200011181818 DOT NAA03898 AT envy DOT delorie DOT com>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Sat, 18 Nov 2000 13:18:56 -0500
> From: DJ Delorie <dj AT delorie DOT com>
> 
> If the putc macro becomes too complex, gcc will refuse to inline it.

We could check whether we come anywhere near that point, if we cared.

> It's also worth it to keep an extra comparison out of the macro; we
> already have a comparison for when the buffer's full, we don't need
> another one in the macro.

I don't see how can we avoid the other test.  We can move it from
__putc_raw to _flsbuf, like Rich did, but we cannot avoid it
altogether, because then we will pay much more, in having the control
flow make all the other tests which we know will fail for string
buffers.