On 08/29/2013 04:30 AM, Amos Jeffries wrote:
> On 29/08/2013 3:58 a.m., Alex Rousskov wrote:
>> On 08/28/2013 09:31 AM, Tsantilas Christos wrote:
>>> On 08/28/2013 06:04 PM, Alex Rousskov wrote:
>>>> What do others think? Is this important enough to fix?
>>>>
>>>>
>>>> If we decide proper support for foo="bar and baz" syntax is important,
>>>> the biggest question for me is whether we should
>>>>
>>>> * change the callers to deal with three tokens (option name, equal
>>>> sign,
>>>> and option value) or
>>>>
>>>> * change the parser to hide the quotes (producing a single complex
>>>> token
>>>> with "=" inside but without quotes so the callers work as is)
>>> Looks that the first is the correct.
>>> I am seeing many problems in the second solution. Valid tokens may
>>> include "=", for example a url.
>> Indeed. Glad we agree.
>
> Yes. I think the best way to do this is to have an optional extra
> delimiter char passed in to NextToken. Similar to how we could
> previously add '=' to the w_space tokens used by strtok().
>
> The callers are all known and currently checking for 'foo=' explicitly.
> It is not too much extra work to locate them, just to alter and test.
I am not sure that will gain anything with this. Because in this case
too we have to fix the parsing parameter code which expects to read such
tokens.
In this case we will have code similar to:
char *var = NextToken(&sep);
if (strcmp(var, "foo") == 0) {
if (sep != '=') {
error;
}
}
In the case we are consider "=" as separated token we have to write:
char *var = NextToken(&sep)
if (strcmp(var, "foo") == 0) {
char *sep = NextToken();
if ( strcmp(sep, '=') != 0) {
error;
}
}
I am thinking that the second approach when the quoted values are on
will allow also:
foo="bar and baz"
foo= "bar and baz"
foo = "bar and baz"
"foo" "=" "bar and baz"
But I believe is not bad.
I have not strong opinion. This option is not bad...
>
> It would also help with the "parameters()" syntax to be able to pass in
> '(' as the extra delimiter.
>
>
> Alternatively what about passing the expected token type as optional
> parameter to NextToken() and handling the existence of regex, Eol, '(',
> '=', or w_space based on that?
This is similar with what you are doing now. We are using NextToken,
RegexToken and NextQuotedOrToEol, so your suggestion is to add a new
NextEqSeperatedToken() and merge all these methods to NextToken.
Implement a NextEqSeparatedToken() looks that required to keep
compatibility with legacy parser...
>
> Amos
>
