Steven Schveighoffer wrote:
"Sean Kelly" wrote
Andrei Alexandrescu wrote:
Someone mentioned an old bug in std.file.read here:
http://www.reddit.com/r/programming/comments/7xnty/walter_bright_on_porting_d_to_the_mac/
Two programmers sent in patches for the function. Which is to be
committed and why? (Linux versions shown. Apologies for noisy line
breaks.)
Neither one. std.read is intended to read the contents of a file in bulk
into memory. If a file size is zero then the size of the data available
is either zero (expected case) or unbounded (screwy *nix case). Streaming
operations should be used on unbounded virtual files, not std.read.
Then you have just created for yourself a never ending bug report :) I
think reading /proc and /sys files is an essential part of writing scripts
and useful utilities. std.file.read is especially useful since most of the
time these files are very tiny, meant to be read all at once. If this
functionality *is* forbidden from std.file.read, then a
std.file.readUnbounded should still be available. Complaining that *nix
isn't pure enough for the likes of D isn't very practical.
I view the usage of fstat to get the file size as being an optimization, not
a validation of the OS' sanity.
I totally agree. The useful spec of std.file.read should be "reads the
file to exhaustion in a buffer and returns it", not "if the size
according to fstat is the same as the actual file size, /proc stuff and
concurrent access against the file notwithstanding, reads exactly that
many bytes in a buffer and returns it. Otherwise, leaves you scratching
your head." And yes, using fstat is just a little irrelevant
implementation trick, not something that conditions the workings of read.
Andrei
