Re: reentrant flex, bison glue

[Akim Demaille]

| In non-reentrant flex, yyleng was never a local variable. It is an extern
| global variable. It is accessible from the parser, and also from "helper"
| functions that are used in flex actions. 

OK, that's the bit I was lacking to understand.  I didn't know some
other people than yylex wanted to have yyleng.  Given that it is
significant only from within yylex, I thought it was local.  And then,
helper functions could get it via its parameters.

| The reentrant API doesn't want to
| restrict access to yyleng to within yylex() only.

Wow.

| Some code might clear it all up. Here's what NON-rentrant flex might generate
| (not EXACTLY, of course):
| 
|   int yyleng;
|   char * yytext;
|   a_lot_more_globals;
| 
|   int yylex() {   
|      ...
|   }
| 
| And here's what reentrant flex might generate:
| 
|   struct yyglobals {
|      int  leng_r;
|      char* text_r;
|      a_lot_more_globals;
|   };
| 
|   #define yytext (G->yytext_r)
| 
|   int yylex( struct yyglobals* G){
|      ...
|   }
| 
| The values yylval, and yylloc are "special" in that they aren't technically
| flex variables -- they are generated by bison. But they are meant to be
| accessed by the user from within the scanner, just like the other flex
| variables. So it makes sense to present them to the user in the same
| manner as the other variables.

I'm sorry to insist, but I still don't understand what kind of
function your are referring to.


The thing is, you are putting a contract onto us.  You are imposing an
interface onto Bison, where there has never been one before.  For
instance, we do have parser objects now, and as it's a new feature, we
are certainly not bound to the current C interface.  But this
reentrant-bison might push users towards a wrong direction.  Sure, I
guess it is not mandatory.


In particular because I have still not seen what exact gain the users
can be expect from this feature, I'm even more worried about this
additional contract that Bison didn't sign.  If the gain is obvious,
then my fears will certainly be forgotten.  What Flex functions other
than yylex could have (could be willing to have) an access to yylloc
and yylval?