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