lex icon indicating copy to clipboard operation
lex copied to clipboard

EOF error about windows line endings.

Open krishna116 opened this issue 3 years ago • 8 comments

I build this lex tool pass on Windows system platform using MSYS2, but when I compile a minimal lex souce code using command ./lex -o test.c test.txt, it always show error message "Error: EOF before %}".

I google it and got this: https://stackoverflow.com/questions/8226993/premature-eof-error-in-flex-file

I think there may be invisible chars influenced the parser, so I change the Windows text line ending(CR LF) to Unix line ending(LF) and it worked, so I think this lex cannot handle Windows line ending correctly.

Follow is the test.txt.

%{
int yylineno;
%}

%%

^(.*)\n  {printf("%4d\t%s", ++yylineno, yytext);}

%%

int main(int argc, char *argv[]) {
	yyin = fopen(argv[1], "r");
	yylex();
	fclose(yyin);
}

Thanks.

krishna116 avatar Aug 11 '22 14:08 krishna116

please confirm whether #5 fixes this.

rofl0r avatar Aug 12 '22 07:08 rofl0r

rofl0r, I tested it, the error message is gone, but it has some problem:

  1. If the main functionint main(){...} do not end with new line, the generated code is wrong.
  2. The generated code cannot compiled by GCC, follow is the error message.
$ ./lex -o test.c test.txt
$ gcc test.c -o test
test.txt:342:1: error: stray ‘\1’ in program
test.txt:342:2: error: stray ‘\17’ in program

Thanks.

krishna116 avatar Aug 26 '22 04:08 krishna116

pushed 9065faa to #5 branch, i suspect that was the issue causing the generated nc*.h headers to contain sequences of \r\n instead of \n. please confirm whether recompiling lex with this change fixes 2. as for 1, this appears to be a separate issue and i wonder whether it's worth spending time trying to debug and fix it, since IIRC posix demands that C input files need to be terminated with a newline.

rofl0r avatar Aug 26 '22 13:08 rofl0r

The commit 9065faa didn't fix 2. If you run command xxd -g 1 test.c, you can see the last line have "01 0f", it is the problem:

00002a10: 0d 0a 09 75 6e 70 75 74 28 63 29 3b 0d 0a 09 7d  ...unput(c);...}
00002a20: 0d 0a 01 0f                                      ....

If I remove "01 0f", then it can be compiled by GCC successfully. By the way, I should add a line "int yywrap(){return 1;}" in the test.txt before compile it by lex.

Thanks.

krishna116 avatar Aug 27 '22 11:08 krishna116

pushed a couple more commits to that branch. since you didnt provide a new test.c which i could vbindiff against the correct result from lex compiled on linux, i made it work with my pellescc wrapper for Pelles C compiler and wine. the windows binary so compiled now produces identical output to the linux version, which can then in turn be compiled too.

rofl0r avatar Aug 27 '22 23:08 rofl0r

I have test it, attach the test.zip, I don't know why there always is a "01 0f" at the file end.

krishna116 avatar Aug 28 '22 08:08 krishna116

that's odd. did you really check out the branch of #5 , ran make clean , and compiled everything anew ? your test.c is identical to your previous one, except addition of int yywrap, so it appears as if none of the changes i did in that branch would have any effect, but that cant be the case.

rofl0r avatar Aug 28 '22 13:08 rofl0r

I downloaded multiple lex package, and I think I confused with them, I'm sorry. I have removed all of them, download the latest branch and test it again, it's ok. Thank you.

krishna116 avatar Aug 29 '22 00:08 krishna116