bug in gmp_fprintf?

[Torbjörn Granlund]

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
problems.

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.

BSD:
    One character of push-back is guaranteed, but as long as there is
    sufficient memory, an effectively infinite amount of pushback is
    allowed.

GNU:
    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
worse:
    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.


-- 
Torbjörn
Please encrypt, key id 0xC8601622