Re: [vpp-dev] unformat %s eats newlines

[Dave Barach (dbarach)]

Folks who need even slightly bulletproof configuration methods should use 
binary APIs: directly from C or through one of several language bindings.

Debug CLI is a developer’s tool, subject to change without notice, and 
supported at the implementer’s discretion.

Extra and/or unparsed input should not go unnoticed: the next function up the 
parse stack will complain.

IIWY I’d leave unformat(…) alone.

HTH… D.

From: Andreas Schultz [mailto:andreas.schu...@travelping.com]
Sent: Friday, February 2, 2018 3:26 PM
To: Dave Barach (dbarach) <dbar...@cisco.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] unformat %s eats newlines

Dave Barach (dbarach) <dbar...@cisco.com<mailto:dbar...@cisco.com>> schrieb am 
Fr., 2. Feb. 2018 um 19:22 Uhr:
Why not simply:

while (…)
  {
if (unformat(input, “name %s”, ))
  ;
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> 
[mailto: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<mailto: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%_", )

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

Re: [vpp-dev] unformat %s eats newlines

[Andreas Schultz]

Florin Coras  schrieb am Fr., 2. Feb. 2018 um
18:57 Uhr:

> Not exactly the most elegant solution but have you tried adding a space
> after the string to be parsed?
>

Tried that, but doesn't help.

Andreas

Florin
>
> > On Feb 2, 2018, at 9:47 AM, Andreas Schultz <
> andreas.schu...@travelping.com> wrote:
> >
> > 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%_", )
> >
> > 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
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] unformat %s eats newlines

[Andreas Schultz]

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”, ))
>
>   ;
>
> 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%_", )
>
>
>
> 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

Re: [vpp-dev] unformat %s eats newlines

[Dave Barach (dbarach)]

Why not simply:

while (…)
  {
if (unformat(input, “name %s”, ))
  ;
else if (…)
  ;
else
 break;
  }

if (<didn’t parse required args>)
return clib_error_return (0, "parse error: '%U'",
  format_unformat_error, input);

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%_", )

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

Re: [vpp-dev] unformat %s eats newlines

[Florin Coras]

Not exactly the most elegant solution but have you tried adding a space after 
the string to be parsed?

Florin

> On Feb 2, 2018, at 9:47 AM, Andreas Schultz  
> wrote:
> 
> 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%_", )
> 
> 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

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] unformat %s eats newlines

[Andreas Schultz]

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%_", )

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