On Feb 20, 2014, at 22:11 , Craig Barnes wrote:
It has to do that some artificial limitations are discussed that simply do not exist.
Not even on Windows which only translates line endings, not \0.
For the line ending! And the ISO C standard paper I found says:
The external representations in a text file need not be identical to the internal representations, and are outside the scope of this International Standard.
NOTHING ELSE! Aside that lines must at least be 254 bytes long:
An implementation shall support text files with lines containing at least 254 characters, including the terminating new-line character. The value of the macro BUFSIZ shall be at least 256.
No it is probably called according to the standard, the same ISO draft copy I found says (like the man pages on Linux and Mac):
The fgets function reads at most one less than the number of characters specified by n from the stream pointed to by stream into the array pointed to by s. No additional characters are read after a new-line character (which is retained) or after end-of-file. A null character is written immediately after the last character read into the array.
It does NOT say:
MAY stop on \0
it does NOT say:
MAY copy, or clobber, additional bytes after the \n was encountered.
Or similar magic some try to imply here.
It also does not say interpret the returned string purely on the first \0 terminator. It explicitly states the NEW-LINE CHARACTER (WHICH IS RETAINED) which makes this the obvious delimiter when reading in lines newline delimited.
Why is it you insists so much to refuse to improve a Lua core function to return more precisely what the underlying system actually returned?