| Message ID | 5596731F.20309@fau.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Jul 3, 2015 at 1:33 PM, Andreas Ruprecht <andreas.ruprecht@fau.de> wrote: > On 07/03/2015 12:46, Ulf Magnusson wrote: >> >> Except for scattered accidents like in the original message, which are >> hopefully pretty rare and easy to fix, the only documented thing that depends >> on that lexer sloppiness is the ---help--- "token". >> >> I'd just add "---help---" as another T_HELP alias (or get rid of it altogether, >> but that's probably more work than it's worth). Tightening things up should be >> safe after that. >> >> /Ulf >> > > So we might want to do something like the attached patch, right? > > Unfortunately, when I generate the zconf.{hash,lex,tab}.c files on my > machine, they have some notable differences to the _shipped versions: > > ruprecht@box:linux-next$ diff -u zconf.tab.c zconf.tab.c_shipped > - return yyresult; > + /* Make sure YYID is used. */ > + return YYID (yyresult); > > and I can't find any Documentation on how to properly rebuild the > _shipped files... Does anybody have a hint on that? > > Regards, > > Andreas Yup, something like that. Been too long, so I don't remember either, though I don't remember having to do anything special. I'm heading off to bed soon, so probably shouldn't be thinking. Could take a look tomorrow if there's still a problem. :) /Ulf -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On vr, 2015-07-03 at 13:33 +0200, Andreas Ruprecht wrote: > Unfortunately, when I generate the zconf.{hash,lex,tab}.c files on my > machine, they have some notable differences to the _shipped versions: > > ruprecht@box:linux-next$ diff -u zconf.tab.c zconf.tab.c_shipped > - return yyresult; > + /* Make sure YYID is used. */ > + return YYID (yyresult); Different version of bison? > and I can't find any Documentation on how to properly rebuild the > _shipped files... Does anybody have a hint on that? One of my many, many pet peeves: patches touching _shipped files like these should mention the command line that was used. Because now everyone is expected to figure that out themselves. Bonus points for mentioning the version of the tool that was used. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 3, 2015 at 1:40 PM, Ulf Magnusson <ulfalizer.lkml@gmail.com> wrote: > On Fri, Jul 3, 2015 at 1:33 PM, Andreas Ruprecht > <andreas.ruprecht@fau.de> wrote: >> On 07/03/2015 12:46, Ulf Magnusson wrote: >>> >>> Except for scattered accidents like in the original message, which are >>> hopefully pretty rare and easy to fix, the only documented thing that depends >>> on that lexer sloppiness is the ---help--- "token". >>> >>> I'd just add "---help---" as another T_HELP alias (or get rid of it altogether, >>> but that's probably more work than it's worth). Tightening things up should be >>> safe after that. >>> >>> /Ulf >>> >> >> So we might want to do something like the attached patch, right? >> >> Unfortunately, when I generate the zconf.{hash,lex,tab}.c files on my >> machine, they have some notable differences to the _shipped versions: >> >> ruprecht@box:linux-next$ diff -u zconf.tab.c zconf.tab.c_shipped >> - return yyresult; >> + /* Make sure YYID is used. */ >> + return YYID (yyresult); >> >> and I can't find any Documentation on how to properly rebuild the >> _shipped files... Does anybody have a hint on that? >> >> Regards, >> >> Andreas > > Yup, something like that. Been too long, so I don't remember either, > though I don't remember having to do anything special. > > I'm heading off to bed soon, so probably shouldn't be thinking. Could > take a look tomorrow if there's still a problem. :) > > /Ulf Or add '---help---' to zconf.gperf I guess, to avoid special-casing it. Would need to add '-' to the n [A-Za-z0-9_] definition in zconf.l in that case too. That should be safe provided the gperf part works out, since zconf.y should verify that the T_WORD has the expected form. (As a side note, the first token on a line is always a keyword, except for within help texts, which are handled specially.) I guess that might change the meaning of lines like "foo-bar" if '-' is introduced as an operator, but that seems kinda academic as 'foo' would probably still be a keyword. It's already broken due to the <PARAM> regex ({n}|[-/.])+ having '-' in it too. /Ulf -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 3, 2015 at 2:39 PM, Ulf Magnusson <ulfalizer.lkml@gmail.com> wrote: > On Fri, Jul 3, 2015 at 1:40 PM, Ulf Magnusson <ulfalizer.lkml@gmail.com> wrote: >> On Fri, Jul 3, 2015 at 1:33 PM, Andreas Ruprecht >> <andreas.ruprecht@fau.de> wrote: >>> On 07/03/2015 12:46, Ulf Magnusson wrote: >>>> >>>> Except for scattered accidents like in the original message, which are >>>> hopefully pretty rare and easy to fix, the only documented thing that depends >>>> on that lexer sloppiness is the ---help--- "token". >>>> >>>> I'd just add "---help---" as another T_HELP alias (or get rid of it altogether, >>>> but that's probably more work than it's worth). Tightening things up should be >>>> safe after that. >>>> >>>> /Ulf >>>> >>> >>> So we might want to do something like the attached patch, right? >>> >>> Unfortunately, when I generate the zconf.{hash,lex,tab}.c files on my >>> machine, they have some notable differences to the _shipped versions: >>> >>> ruprecht@box:linux-next$ diff -u zconf.tab.c zconf.tab.c_shipped >>> - return yyresult; >>> + /* Make sure YYID is used. */ >>> + return YYID (yyresult); >>> >>> and I can't find any Documentation on how to properly rebuild the >>> _shipped files... Does anybody have a hint on that? >>> >>> Regards, >>> >>> Andreas >> >> Yup, something like that. Been too long, so I don't remember either, >> though I don't remember having to do anything special. >> >> I'm heading off to bed soon, so probably shouldn't be thinking. Could >> take a look tomorrow if there's still a problem. :) >> >> /Ulf > > Or add '---help---' to zconf.gperf I guess, to avoid special-casing it. Would > need to add '-' to the > > n [A-Za-z0-9_] > > definition in zconf.l in that case too. > > That should be safe provided the gperf part works out, since zconf.y should > verify that the T_WORD has the expected form. (As a side note, the first token > on a line is always a keyword, except for within help texts, which are handled > specially.) ...or that it's not a T_WORD rather, but a command. :P > > I guess that might change the meaning of lines like "foo-bar" if '-' is > introduced as an operator, but that seems kinda academic as 'foo' would > probably still be a keyword. It's already broken due to the <PARAM> regex > ({n}|[-/.])+ having '-' in it too. > > /Ulf /Ulf -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l index 200a3fe..84a5d05 100644 --- a/scripts/kconfig/zconf.l +++ b/scripts/kconfig/zconf.l @@ -106,7 +106,15 @@ n [A-Za-z0-9_] zconflval.string = text; return T_WORD; } - . + "---help---" { + /* Support old syntax for help statement */ + return T_HELP; + } + . { + fprintf(stderr, + "%s:%d:warning: ignoring unsupported character '%c'\n", + zconf_curname(), zconf_lineno(), *yytext); + } \n { BEGIN(INITIAL); current_file->lineno++; @@ -132,7 +140,6 @@ n [A-Za-z0-9_] BEGIN(STRING); } \n BEGIN(INITIAL); current_file->lineno++; return T_EOL; - --- /* ignore */ ({n}|[-/.])+ { const struct kconf_id *id = kconf_id_lookup(yytext, yyleng); if (id && id->flags & TF_PARAM) {