 |
lua-l archive |
|
|
||
|
Edgar Toernig wrote:
Daniel Stephens wrote:On OSX my experience doesn't match your explanation, for two reasons...Did you try the "lua -" + CTRL-D test with and without the line?
Yes, it works just fine on OSX, but either way, if that's failing it's much more likely the fault of the call to ungetc earlier that doesn't bother to check if c == EOF.
In this code, feof is completely unnecessary.Only if you never call fread/fgetc/etc after you've seen an EOF. But if you call one of these routines again with the expectation that they will report EOF again you *may* lose.
I disagree, it's unnecessary as long as PREVIOUS reads bothered to check feof (which is what they're SUPPOSED to do, but the calling module (luaL_loadfile in this case) isn't very consistent there).
I'm not the only person who interprets the documentation to mean 'call feof after you've had a read fail', my experience has been that subsequent reads will fail immediately until you clear the flag, but I'll admit that i didn't do exhaustive testing on the latter.This feof-test is at the wrong place. First, you may already be at EOF (happens in Lua) but more important, the fread may return > 0 but may have also set feof. If you call fread again and lf->f is a terminal it will wait for the next line or CTRL-D. To circumvent this, the feof-test has to be before the fread.