Mail Archives: djgpp-workers/2000/12/30/08:27:23
Hello.
A while ago I submitted patches to add snprintf() to DJGPP, based on Alain
Magloire's original code. I seem to recall that everything was OK apart
from one issue - whether to put the handling for a full string buffers in
__putc_raw() (see libc/file.h) or in _flsbuf(). By a string buffer, I mean
that the buffer in the FILE struct points to a user-supplied string and
the _IOSTRG
flag is set.
Reasons for putting handling in __putc_raw():
* Speed
Reasons for putting handling in _flsbuf():
* Concerns about gcc not inlining __putc_raw() if it gets too long.
* Trying to keep __putc_raw() macro simple - keeping the number of special
cases to a minimum.
The last patch I sent was in a mail entitled "snprintf() diff, take 4",
which had the handling in _flsbuf().
Here are some usage cases of snprintf():
(i) snprintf() called to find buffer space needed to store formatted
string.
(ii) snprintf() called to write formatted string into buffer that is the
same or greater size.
(iii) snprintf() called to write formatted string into buffer that is
slightly too small.
In case (ii), _flsbuf() will never be called, so it's irrelevant where the
handling is. For case (iii), _flsbuf() will be called a few times, so it
is not so important where the handling is. For case (i), _flsbuf() will be
called for every character.
So, how often is snprintf() used in case (i)? Using GNU id-utils I looked
at ~444MB of various program sources on my Linux box (admittedly including
object files) for occurrences of snprintf(). There were 674, none of which
were case (i). So the uses fall into cases (ii) and (iii).
Conclusion: It doesn't matter too much where we put string buffer
handling, speed-wise.
My opinion: I vote for simplicity, i.e. putting the handling in _flsbuf().
I hope we can get snprintf() into DJGPP soon.
Bye, Rich =]
--
Richard Dawe
[ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]
- Raw text -