On 08/28/2013 07:30 PM, 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:
>>> foo= "bar and baz"
>>> foo = "bar and baz"
>
> Please no.
Just to make sure, do you realize that from general parsing code point
of view, it would be harder to prohibit the above than to support it?
>> And yes, all of your three variants above become supported automagically
>> then.
>>
>> We can be more strict and require no whitespace around "=" (like some
>> old shells do for assignment), but I am not sure that we should because
>> it is usually best to let admin to use as little or as much whitespace
>> as she feels is best for the given context.
>
> The current no-strict configuration file does not permit whitespace. I
> don't think allowing it in a more strict syntax is a good idea.
"strict" in this context means something like "formal grammar with few
context-based exceptions" rather than "we are afraid of whitespace". It
is much easier to declare that all unquoted whitespace is ignored than
to say that there should be no whitespace around the "=" token used
inside a directive parameter.
To avoid any misunderstanding, I do not think many folks will use
space-rich "foo = bar" syntax in a directive option. It is not needed
there. However, it is easier to support it rather than not support it,
and it may be useful elsewhere.
>>>> * change the callers to deal with three tokens (option name, equal
>>>> sign,
>>>> and option value) or
>>> Looks that the first is the correct.
>> 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().
I do not think this is the best way to handle this, at least not at the
parser level. The first NextToken() call should return "foo". The next
NextToken() call should return "=".
If there is a lot of code that extracts two tokens and makes sure that
the second one is "=", then we can add a convenience wrapper for that,
but that wrapper will still call NextToken() to get the individual token
values.
I have not checked, but I suspect it would be even more convinient to
have a wrapper that returns option value as well:
NextKeyValue(String &key, String &value, bool valRequired = false);
or something like that.
> 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.
>
> 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?
One of the key ideas behind "strict syntax" is that the token "type" can
be and is determined by the parser (simple token, quoted string, regular
expression, number, etc.) and not the caller. This is not the only way
to support better syntax rules, but it is overall simpler and more
flexible than the caller-determines-token-type alternatives (because the
code can manipulate tokens with respect to comments, macros, line
continuation, whitespace, and such without relying on callers to parse
each character).
HTH,
Alex.
