bug in gmp_fprintf?
tg at gmplib.org
Tue Nov 24 08:34:39 UTC 2015
nisse at lysator.liu.se (Niels Möller) writes:
The first thing to do when optimizing anything using (f)getc, is to use
getc_unlocked (and flockfile/funlockfile outside of the loop).
Maybe that's enoough to get reasonable speed?
I didn't look where the callback ends. Perhaps it is unlocked.
Unfortunatly, getc_unlocked is POSIX, not C90, so unless we've found it
to be supported everywhere in practice already, we might run into
I don't think we need to lock the stream.
I'm suspect it's unportable to ungetc more than one character.
Both GNU ad BSD documents it as capable of multiple pushbacks, sort of.
One character of push-back is guaranteed, but as long as there is
sufficient memory, an effectively infinite amount of pushback is
ungetc() pushes c back to stream, cast to unsigned char, where it is
available for subsequent read operations. Pushed-back characters
will be returned in reverse order; only one pushback is guaranteed.
The latter docs is more vague of when it may fail. But Solaris is
Four bytes of push-back are guaranteed. If ungetc() is called too
many times on the same stream without an inter- vening read or
file-positioning operation on that stream, the operation may fail.
I suppose we cannot really use it as I want, except on BSD. I don't
know what the C standards say.
Please encrypt, key id 0xC8601622
More information about the gmp-bugs