lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Friday, February 21, 2014, Cezary H. Noweta <> wrote:
On 2014-02-21 08:35, René Rebe wrote:

it does NOT say:

MAY copy, or clobber, additional bytes after the \n was encountered.

It *does* say this implicitly, i.e. it *does not* say this is
prohibited. In the simplest case, ,,fgets()'' can memset all an outut
buffer with zeroes at the beginning of its operation to verify that all
the buffer is writable. Untouched buffer is present solely in an
EOF-at-the-beginning case.

{To René: Your patch has one major disadvantage: it assumes that
the buffer will not be touched beyond terminating null character. In
general it *is not* true. Lua is sitting on top of C and not on top of
your implementation of C.}

,,fgets'' *is not* for reading zeroes (no matter: from text or from
binary streams). Using ,,fgets'' is ,,implementation detail'' which
should be mentioned in a documentation at least (or maybe, at most?).

BTW. It is unreasonable, how many can be told about differences between
text/binary streams, in the world, where 99.99% implementations *does
not* distinguish between them. :-)

-- best regards

Cezary H. Noweta

What we all think it should do is a factor. What your sub-30 year old trying to script a Lua-extended application by reading in a machine-generated "text" file is another importantant factor. 

This isn't a vote. If it were a vote, mine would be for raising an error. Especially given that you could also read chunks ("*n") at a time and parse the stream in anyway you please, 0's and all.  

Lua's library functions are lightweight bindings around C, for the most part. Radically different behavior than C would bring too much complexity. However, catching behavior that would confuse someone without a masters in CSCI seems to be in line with the role that Lua plays

The update to the manual is also an improvement and perhaps it is enough?