Kang-Che Sung (宋岡哲)

Dammit. No! #133 and #194 are different! #133 is about calling exit in _generated scanner_ code, while #194 is about exiting of flex generator itself.

Any test case that demonstrates the wrong behaviour? We don't need in-code explanation (we developers can read code), we just need to ensure the bug exists by providing a test...

When you reported this, you should have a test case that demonstrates the gcc error you've talking about. Could you give us the test case? Sorry, I'm here just to...

@westes I'm not sure where the cause of the fopen() error is, but I see flex prints a fopen error message without strerror(errno) text, which is a usability bug already.

@blastwave It seems that the usability problem I mentioned already has a patch. Could you please apply #305 and try building again, and tell us exactly what "can't open" message...

@blastwave It's quite difficult to diagnose a problem like this. You haven't tried building against the master branch, right? Because the patch changes the lexer source file (see the .l...

@blastwave Building against master branch has nothing to do with the software being release grade or not. It's about whether you understand the build process, so that we no longer...

@username34 The "implicit declaration of function 'reallocarray'" error is fixed already in master (#241). Try building the master branch or specify `'ac_cv_func_reallocarray=no' 'ac_cv_func_reallocarr=no'` as two arguments to `./configure` as workaround.

Update (2020-02-15): With stage1scan.c being deterministic, I added a byte comparison check (stage2scan.c) here that ensures the generated flex program can build the scanner of itself flawlessly.

Updated according to @jannick0 's comments. The new version of this pull request now preserves stage2scan.c even if comparison fails. I don't think generating a diff output is good as...