On 21.01.2018 01:03, Tanu Kaskinen wrote:
On Fri, 2018-01-19 at 14:23 +0100, Georg Chini wrote:
On 18.01.2018 23:20, Tanu Kaskinen wrote:
On Wed, 2018-01-17 at 16:12 +0100, Georg Chini wrote:
On 14.01.2018 21:47, Tanu Kaskinen wrote:ry from
the heap are quite heavy operations, and your approach will do a lot of
those operations. Even reading a simple integer will, I suppose,
involve first allocating a new string. I can't say for sure that the
performance penalty makes any practical difference, but my intuition
says that we should use the approach that I proposed that requires far
fewer heap memory allocations.
I can accept the argument that my solution unnecessarily allocates
strings in some situations. Though I do not think it has much practical
impact, most of it can be avoided by using special functions to retrieve
numbers or booleans. I am also quite sure that a function similar to the
*_split_in_place() functions can be implemented to completely avoid
the allocation of unnecessary strings.
An in-place split function seems feasible indeed.
Since your splitting function can be modified to avoid mallocs, I'm not
so strongly against it any more.
Sounds good, I sent a new patch set.
It looks like we're anyway going to
need a bunch of "helper" functions, so there's not that much difference
between our approaches, mainly list parsing details are affected
somewhat. How to organize the helper functions is an open question,
since you have so far opposed my pa_message idea, and haven't provided
a proper alternative for keeping parameter writing state.
Can you perhaps explain your idea again? Maybe I just opposed
because I did not understand what you proposed. I agree that we
need helper functions to read and write values and if you like to
include the braces around the parameter in the helper functions,
I can live with it as well. What do you mean by "keeping parameter
writing state"?
Here's one more topic for discussion: could we please support null
values? One thing that has caused some trouble with D-Bus is that it
doesn't properly support null values. Generally nulls could be encoded
with "{}", but that doesn't allow distinguishing between an empty
string or list and null. Maybe that distinction is not needed?
For numbers and booleans an empty element can be treated
as NULL value, for a string I guess it does not matter that much
if it is empty or NULL.
My parsing function supports empty elements and returns an
empty string. A special case is an empty list, but in this case
the function would return "end of string" when you try to
access the first element in the list.
How should reading and writing nulls work? Writing nulls is not
complicated, we could just have pa_message_write_null() (or since we
probably will have a "raw string append" function, it's trivial to just
append "{}" manually). Reading nulls is less obvious.
All reading functions could have an "is_null" parameter:
double double_var;
int is_null;
ret = pa_message_read_double(msg, &double_var, &is_null);
If the is_null parameter isn't provided (i.e. is itself NULL), the
function could fail if it encounters null.
If we define that NULL is represented by the "special element"
{} it is very easy to determine if an element is empty, because
in this case, the length returned by the parsing function will be 0.
So I don't think we need to include an allow_null parameter in
the helper function (unless we treat a sequence of white spaces
like an empty element), because in cases where it is important,
we can check the length of the element before calling the helper.
Currently, parsing a value (including full error check) would look
something like
ret = pa_split_message_parameter_string(list, max_length, &start_pos,
&length, NULL, &state);
if (ret == 0)
handle empty element;
if (ret == -1)
handle parse error;
/* start_pos contains now the first valid character of the element
* after { and length the length of the element without closing
* bracket */
ret = pa_message_read_double(start_pos, length, &double_var)
Strings would not need a (read) helper function because they can
be directly returned by the parsing function.
Alternatively, if it's too ugly to have the is_null parameter in all
reading functions, there could be separate "_or_null()" functions
alongside the regular functions, e.g. pa_message_read_double_or_null().
And still one more topic: we might want to support arbitrary binary
data at some point. This could be supported by escaping non-ascii bytes
with \xnn (with n being a hexadecimal number). This escaping support
should exist from the beginning. Do we perhaps want to support \n, \r
and \t as well?
I do not think this must be supported from the start. "Binary data"
would be a different data type than "string" and have special
helper functions that can handle escaping.
This is different from escaping the control characters.
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
