Purge phantom fp parameter.
Add missing parameters and throws info.
Fix File.readln(buf) example to use char[] buf for reuse, not string.
Fix swapped readln() and File.readln() examples.
Separate readln() and readln(buf) docs because the behaviour and
return types are different.
Fixes an issue where `readln!S` did not forward the type "S" in `stdin.readln()` => `stdin.readln!S()` (that was my mistake, sorry)
Fixes an issue where `File.readln!S` assumed S was an "immutable string type". This should work:
char[] buf;
buf = myFile.readln!(char[])();
While buf is not reused after each call, there should be nothing preventing the user for mutating if he so (explicitly) wishes.
Added/improved unittests a wee little bit.
byLine expects readln to return with an empty buffer on end-of-stream,
which readln does not do for wchar and dchar. Also, the readln variant
that takes a terminator range returns incorrect concatenations of
lines because of the same issue. Fixed by setting buffer.length=0 in
readln for this case. Unit test updated to detect this issue.
Now that std.process will support pipe creation, the name isPipe will
only cause confusion, as it will in fact be false for "normal" anonymous
pipes. It is only true for files opened by popen(), and its purpose is
simply to ensure they are closed with pclose().
Updated documentation for all the C-like member functions \
(and the File ctor) to specify exactly what gets thrown when.
(note: Exceptions in std.stdio are a mess and should be made
more consistent. Also, it seems some member functions that
should check if the file is opened do not, but I don't know
if that might be intentional (as the C functions should fail
anyway, resulting in a throw))
There is absolutely no need to explicitly flush a stream on new line because it is expected only for console output which is line buffered or unbuffered by default.
Those kind of functions should be placed in druntime,
but the *64 (v) functions as a public interface are actually
deprecated and shouldn't be used anymore.
Druntime takes care that the normal stat, fopen, calls support
large files, if __USE_FILE_OFFSET64 is defined (which is what
the new C API does as well)
Note: It's actually important to use the functions from
core.sys.posix.stdio as the functions in core.stdc.stdio
are not large file aware. This is probably a bug in druntime.
This is just me committing to maintain my code additions to
these modules. We should, in general, use these author lists
more so we know who's responsible for the various modules.
