Re: new module 'freadptr'

[Bruno Haible]

What happens with freadahead() and freadptr() after ungetc?

In theory it is possible that an implementation stores the bytes pushed-back
by ungetc in a location that freadahead() does not see. The implementations
that I tested don't do this, but the API should support this. I can see three
possible ways to support this situation:

  (a) Change freadahead(), so that freadahead() after ungetc return 0.
  (b) Change freadptr() so that it returns NULL after ungetc, even though
      freadahead() > 0.
  (c) Add a new API that tests whether the stream is current reading pushed-back
      bytes.

(a) would break the closein.c code. It assumes that when freadahead() there
are no buffers in memory (except for the pushed-back bytes).

(c) may be difficult. I already had problems implementing it on glibc.

So this implements (b).

*** lib/freadptr.h.orig 2008-02-29 00:49:20.000000000 +0100
--- lib/freadptr.h      2008-02-28 23:32:46.000000000 +0100
***************
*** 23,30 ****
  
  /* Assuming the stream STREAM is open for reading:
     Return a pointer to the input buffer of STREAM.
!    If freadahead (STREAM) > 0, the result is a pointer to freadahead (STREAM)
!    bytes.
     If freadahead (STREAM) == 0, the result is not usable; it may be NULL.
     In this case, you should use getc (STREAM), fgetc (STREAM), or
     fread (..., STREAM) to access the input from STREAM.
--- 23,31 ----
  
  /* Assuming the stream STREAM is open for reading:
     Return a pointer to the input buffer of STREAM.
!    If freadahead (STREAM) > 0, the result is either a pointer to
!    freadahead (STREAM) bytes, or NULL.  The latter case can happen after
!    use of 'ungetc (..., STREAM)'.
     If freadahead (STREAM) == 0, the result is not usable; it may be NULL.
     In this case, you should use getc (STREAM), fgetc (STREAM), or
     fread (..., STREAM) to access the input from STREAM.