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

Georg Chini georg at chini.tk
Fri Jan 26 06:38:38 UTC 2018

On 26.01.2018 03:26, Tanu Kaskinen wrote:
> 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.
I already said it is only a benefit if you use the values before the whole
sub-list has been parsed.

There are many situations where parsing the whole message before
using any value seems impractical. Take the list-handlers message.
If you had to read the whole list before using the elements, it would
mean you have to set up some dynamic array to store the values.

More information about the pulseaudio-discuss mailing list