[pulseaudio-discuss] [PATCH 5/5] pactl: Implement list message-handlers

[Tanu Kaskinen]

On Thu, 2018-01-25 at 07:38 +0100, Georg Chini wrote:
> On 25.01.2018 00:26, Tanu Kaskinen wrote:
> > On Wed, 2018-01-24 at 22:01 +0100, Georg Chini wrote:
> > > On 24.01.2018 02:10, Tanu Kaskinen wrote:
> > > > How does validating the brace correctness prevent some values being
> > > > used before all values have been parsed? You're only enforcing brace
> > > > correctness, but if you have a list of doubles, any of the double
> > > > values can be invalid. Nothing is preventing the application from using
> > > > the first values of the list before noticing that a value later in the
> > > > list is invalid.
> > > > 
> > > > I didn't claim that my approach was any better in this regard, you were
> > > > just making impossible-sounding claims about the benefits of your
> > > > approach.
> > > 
> > > I can only repeat myself: My example above shows how this
> > > helps detecting errors before any values are used at all. The
> > > point is, that the consistency check is done before the values
> > > are parsed. This means when pa_split_message_response()
> > > returns a list, the whole list is already checked for consistency
> > > (with the exception of the outer, implicit list). This does neither
> > > prevent later lists from having issues nor does it help against
> > > wrong list values, but at least you should never hit a parse
> > > error within a list. I think it is a big benefit to know in advance
> > > that a list is at least consistent.
> > 
> > I just don't see the big benefit. You have to do error checking for the
> > individual values in any case. The benefit of having the list
> > formatting check early is that reading the individual values can't fail
> > due to list formatting errors, but since there are other error cases,
> > the code complexity for reading a value is exactly the same as without
> > any early list formatting checks (assuming that the application doesn't
> > care about the exact failure reason).
> 
> Strange that you don't see the benefit. In my example, if the y1
> y2 are very high but still acceptable volume values, not catching
> the parse error in advance could even lead to damage of
> hardware or ears.

So this "big benefit" is only for the cases where an application uses
some parameter values before the whole message has been parsed. That's
always a bad idea, so nobody should be doing that, and therefore the
benefit seems very small to me.

-- 
Tanu

https://liberapay.com/tanuk
https://www.patreon.com/tanuk