[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 01/53] xen: add an optional string end parameter to parse_bool()

On 23/08/17 18:33, Juergen Gross wrote:
> Add a parameter to parse_bool() to specify the end of the to be
> parsed string. Specifying it as NULL will preserve the current
> behavior to parse until the end of the input string, while passing
> a non-NULL pointer will specify the first character after the input
> string.
> This will allow to parse boolean sub-strings without having to
> write a NUL byte into the input string.
> Modify all users of parse_bool() to pass NULL for the new parameter.

So I already had plans for parse_bool() during the XSA-226 embaro
period, but couldn't discuss any of them, and this series appeared in
the meantime.

One rather confusing problem we have is that top level booleans behave
differently to sub-booleans.

Top-level booleans support all kinds of ={0,true,yes, ...} qualifiers,
as well as no- prefixes.  sub-booleans may or may not support the
qualifiers, and where they do support the no- prefixes, the same prefix
gets silently eaten for non-boolean suboptions.

I had planned to modify parse_bool() to be

int parse_bool(const char *field, const char *s)

which cases care of considering the "no-" prefix, optionally skips the
field name if it matches exactly, and then performs the current logic on
the remainder of the string.  This way, boolean options should work
consistently wherever they are.

It also means that a lot of custom_params() need simplifying to always
pass intended boolean options to parse_bool().

Could we see about merging this work together, rather than having two
series going and modifying how the parsing works?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.