Open nxg opened 5 months ago
I can't find a spot in the docs that explains this behavior clearly. The best hints I could find are in the sections on multiple buffers, yywrap, and EOF rules.
You need an <
I'm away from my computer but I'll post an example when I'm back.
Thanks for clarifying.
In case it's useful when thinking about the docs, my mental model, when writing what I did, was that when I arrive at EOF
using input()
, I'm doing so ‘legitimately’ (ie, as opposed to my being illegitimately creative with yyinput
, or something like that). It was on that basis that I presumed yywrap
would Do The Right Thing, and that when flex subsequently asked for more input from input()
, it would be told calmly ‘no’.
Or, put another way, my mental model is that flex is itself using input()
to get input, or something equivalent to that, so that I'm working in concert with it if I read from it separately.
If those are bad intuitions, it might be useful for the docs to disabuse the reader fairly explicitly.
The program below works as expected when reading from stdin, but segfaults when it is instead lexing a buffer.
The key thing about this example is that one of the rules uses
input()
to gobble from"!"
to EOF (yes, it looks as if I could use a"!".*
pattern, but that doesn't produce the intended results in the real case; the lexer needs to balance braces, and if I hit EOF when trying to do that, I want to recover gracefully).When run, reading from stdin, I get
That's fine, but when I instead
./eof 'one two !three four'
, which scans the contents of a buffer set up byyy_scan_string
, I get identical program output, followed by a segfault insideyy_get_next_buffer
.I can't work out which part of the flex manual is telling me I should expect that to happen.
The sequence of events seems to be that the lexer is finding its way to the end of file, as expected (and an
<<EOF>>
action confirms this), but not stopping there, despite the presence of thenoyywrap
option, and collapsing when it can't find a ‘next’ buffer.Points:
yywrap
, so it should be getting the message that there is no more input coming.input()
, in the flex manual, is in a case where hitting EOF is reported as an error. Here, I'm doing essentially the same as in that example, but regarding EOF as an acceptable end of the scan.input()
returns 0, notEOF
, at EOF, despite what Sect.8 illustrates (cf. flex repo issue, and links there), and despite the rather mysterious note about a ‘“real” end-of-file’ in Sect.20. I have a suspicion that this remark in Sect.20 is telling me something terribly important, but I can't work out what.Program: