std.file.read implementation contest

[Andrei Alexandrescu]

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