On Sun, Apr 19, 2009 at 1:52 PM, Jim Meyering <[email protected]> wrote: > Andreas Schwab wrote: >> Jim Meyering <[email protected]> writes: >> >>> Sure, but that's not the question. >>> The question is whether we can assume short-read-on-regular-file >>> implies EOF. >> >> I think you can look at it as if you are reading a growing file. > > Makes sense. > But if a regular file is growing, then it's stat.st_size changes. > For files in /proc, stat.st_size is always 0. > > If it is implemented that way, then it would be better > to hide such counter-intuitive details from applications. > > Already, the fact that st_size is 0 for a known- and usually > constant-sized, non-empty file is misleading -- probably contrary > to POSIX, too, given the definition of st_size for a regular file. > > I wonder what would break if those types were changed from S_IFREG > to S_IFIFO. One drawback might be that files in /proc are currently > seekable. FIFO's aren't. > > It's a good thing that so few of the files in /proc are large > enough to be affected.
I guess this doesn't help solve the general problem of reading /proc files under arbitrary kernel versions, but I do find the standard of implementation of /proc files to be low. at least in some kernel versions; st_nlinks is also often wrong on directories, as well. I guess the problem sot st_size is that the code can't easily figure out how much data it will produce without actually generating it; maybe it would be efficient enough to make an overestimate (and perhaps pad the result with newlines). James. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
