On 26.01.2018 21:14, Georg Chini wrote:
> On 26.01.2018 04:22, Tanu Kaskinen wrote:
>> On Thu, 2018-01-25 at 09:08 +0100, Georg Chini wrote:
>>> On 24.01.2018 01:40, Tanu Kaskinen wrote:
>>>> On Mon, 2018-01-22 at 16:19 +0100, Georg Chini wrote:
>>>>> On 21.01.2018 01:03, Tanu Kaskinen wrote: So you're proposing that
>>>>> reading a double should take two function
>>>>> calls. I think the two steps should be merged into one
>>>>> pa_message_params_read_double() function. Then error handling
>>>>> needs to
>>>>> be done only once, rather than twice per value. With this approach,
>>>>> however, the question arises how to deal with nulls.
>>>>>
>>> You are right, it should be folded into one function. I guess the
>>> easiest way to handle NULL's is to have a special return value,
>>> let's say 1 if parsing was OK, 0 if NULL was found and -1 on
>>> parse error, similar to the split function.
>>>
>>> Actually I noticed, that the code above is not correct. After
>>> pa_split_message_parameter_string() three checks need to
>>> be performed:
>>>
>>> 1) ret = 0: This does NOT mean that the element is empty,
>>> it means that the element is completely missing (end of list).
>>> It can still be treated like an empty element.
>> Why should it ever be treated like an empty element? Doesn't that make
>> it impossible to distinguish between an empty element and end-of-list?
>
> The functions are retrieving a single element of a list. In that
> case there is no difference if the element is empty or the
> surrounding list ended (and the element is missing).
You are again right, if you want to read a list with something like
while ((ret = pa_message_param_read_xyz()) != 0) {
}
the return values must indeed be different. This is not included in v4 of
the patches but the fix is trivial. Empty element will then return -2.
For strings, an empty element is not considered an error.
Somehow the v4 patches did not make it to patchwork (yet). Any idea
why? I had a typo in the subject of the cover letter, maybe that's the
reason?
