Re: [PATCH] Unknown cfg function

On 30/08/2013 2:49 a.m., Tsantilas Christos wrote:
> 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...

I'd call it "KeyValueToken()" and which outputs a token of equivalent to
pattern: [a-z] '=' <normal-token>

Amos
Received on Fri Aug 30 2013 - 05:47:52 MDT