[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: fgets() in read_line in liolib.c, C string to \0, LUAL_BUFFERSIZE
- From: Tom Oehser <tom@...>
- Date: Fri, 30 Mar 2001 23:34:41 +0000 (America/New_York)
Two things I see in read_line that might be causing the problem...
(1) fgets terminates what it read with a null- but what if a null is
there in the line? Then Lua will return a partial chunk I think?
(2) read_line looks like it can just fill the LUAL_BUFFERSIZE, and the
return will give no indication whether you got a line of just the
first buffer (the newlines is stripped so you can't check that...)
Given that my total count of newlines is way off, I think that (1) is what
is probably happening. Probably if I read abc\0def\n, fgets reads the
whole thing into the buffer, but Lua parses only up to the \0 ... um, yes,
it is using strlen()... but the file position is still after the \n! And
there is no way to tell...
I guess I would like to see the whole library enhanced to be 8-bit-clean.
I am writing Lua versions of things like cut split head tail wc tee and
other small shell utilities and the like, and this error came up in
testing to make sure they behave the same way the gnu versions do... I ran
a test where the 'split' program split a file with nulls by lines, and got
the nonsense results.
At least please add a note to the docs about it...