Edgar Toernig wrote:
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.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?
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).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'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.