Re: gnulib portability issues

[Rich Felker]

On Sat, Jun 09, 2012 at 10:01:38PM -0700, Paul Eggert wrote:
> On 06/09/2012 09:25 PM, Rich Felker wrote:
> > For seekable input, comparing ftello(f) and the underlying fd offset
> > from lseek(fileno(f),0,SEEK_CUR) would work, but that also will fail
> > for non-seekable input.
> 
> Thanks, that's better than what I wrote.  Perhaps you could write up
> a patch along those lines.  At least it will work for seekable files.

I don't think it's useful if it fails and makes the program misbehave
on pipes. If the result were only needed/used for "optimization"
purposes and doesn't have to be right, we could just either always
return 0 or always return 1, but I'm not clear whether it's intended
that the function always give an accurate result. If yes, there are
usage cases in a potential caller that would be broken by either fake
behavior..

> Come to think of it, a variant might even work for seekable files.
> Use dup2 to move the file descriptor somewhere else.  Close the
> fd.  Keep reading until error, and count the bytes read.  Then
> ungetc all the bytes that you read, in reverse order, and restore
> the file descriptor.  Of course ISO C doesn't guarantee this, but
> it should be fairly portable in practice.

No, ungetc normally can only unget one character. musl is fairly
unique in allowing you to unget more, and this is not really
intentional, just a consequence of the fact that we don't do any
buffer switching for unget.

Did you miss the end of my last email? I already sent a sketch of an
idea similar to yours, and it only needs to unget one character, not
an arbitrary number.

Oh, I see now you want to actually make it return the number of bytes
buffered rather than just the fake minimum number based on a boolean.
If the latter is acceptable though, the stdio_ext.h function
__freading might suffice as an implementation.

> > it might be better to make sense of WHY it's needed/wanted
> 
> Yes, quite true, but that information wasn't communicated to the
> gnulib mailing list.

I'll see what we can find.

Rich