|Thread-safety, lex and yacc. email@example.com (Nicholas Dronen) (2001-03-31)|
|Re: Thread-safety, lex and yacc. firstname.lastname@example.org (2001-04-04)|
|Re: Thread-safety, lex and yacc. email@example.com (Troy Cauble) (2001-04-10)|
|Re: Re: Thread-safety, lex and yacc. firstname.lastname@example.org (John W. Millaway) (2001-04-12)|
|Re: Thread-safety, lex and yacc. email@example.com (Clark) (2001-04-12)|
|Re: Re: Thread-safety, lex and yacc. firstname.lastname@example.org (Ethan Eade) (2001-04-14)|
|From:||Nicholas Dronen <email@example.com>|
|Date:||31 Mar 2001 02:35:00 -0500|
|Organization:||Front Range Internet, Inc. (800.935.6527)|
|Keywords:||lex, yacc, parallel, comment|
|Posted-Date:||31 Mar 2001 02:35:00 EST|
I noticed that yylval is a global variable in the lex file for an
application I'm auditing for thread-safety. In the C++ source file
generated by lex, the variable is global as well. I suspect that this
doesn't bode well for the thread-safety of the application.
We use MKS lex. The reference manual says that yylval is a global
variable. On the other hand, it also says you can use the -DYYALLOC
preprocessor directive to yacc to generate reentrant code. I don't
see where it says anything about the reentrancy of the scanner.
Does anyone have experience with making an apparantly non-thread-safe
lex/yacc code base thread-safe? Suggestions and pointers welcome.
[If you tell flex to generate a C++ lexer, it's thread safe. Haven't
seen a thread-safe yacc but I haven't looked very hard either. It
wouldn't be hard to do. -John]
Return to the
Search the comp.compilers archives again.