lua-users home
lua-l archive

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


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).

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.
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.