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

[Georg Chini]

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.