std.file.read implementation contest

[Sean Kelly]

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 wasn't saying that at all.  But try using this approach on 
/dev/random, for example.  One of the great things about *nix is that 
_anything_ can be represented as a file and therefore operated on via 
the same scripting techniques, however, I think it's an open issue 
whether this behavior lies within or outside the design of std.read.

I do think one could argue that std.read should make a best effort and 
read from such files up to some imposed maximum byte count, but this 
still seems like stretching its intended purpose to me.


Sean