On Fri, Jul 3, 2015 at 2:39 PM, Ulf Magnusson <ulfalizer.lkml@xxxxxxxxx> wrote: > On Fri, Jul 3, 2015 at 1:40 PM, Ulf Magnusson <ulfalizer.lkml@xxxxxxxxx> wrote: >> On Fri, Jul 3, 2015 at 1:33 PM, Andreas Ruprecht >> <andreas.ruprecht@xxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html