Dave Barach (dbarach) <dbar...@cisco.com> schrieb am Fr., 2. Feb. 2018 um
19:22 Uhr:
> Why not simply:
>
>
>
> while (…)
>
> {
>
> if (unformat(input, “name %s”, &name))
>
> ;
>
> else if (…)
>
> ;
>
> else
>
> break;
>
> }
>
>
>
> if (<didn’t parse required args>)
>
> return clib_error_return (0, "parse error: '%U'",
>
> format_unformat_error, input);
>
>
That would mean that malformated optional and random additional stuff would
get unnoticed. CLI verification is already not that strong (the usual while
loop parsing permits random argument order even when the help strings
suggest strongly ordered arguments).
Is there a reason that unformat eats the newline or is just to hard to
change?
Andreas
>
>
> D.
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Andreas Schultz
> *Sent:* Friday, February 2, 2018 12:47 PM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] unformat %s eats newlines
>
>
>
> A typical construct to parse arguments is to use unformat in a while loop
> that checks for UNFORMAT_END_OF_INPUT.
>
> For multiline input that relies on the detection of "\n" in the input
> stream.
>
>
>
> The problem is that a construct like:
>
>
>
> unformat (input, "name %_%v%_", &name)
>
>
>
> eats the newline when it is the only characted following the string to be
> parsed.
>
>
>
> This even break reading a multi line config with exec.
>
>
>
> Regards
>
> Andreas
>
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
