[FFmpeg-devel] [RFC][PATCH] avstring: Add new function av_for_each_pair

[Alexander Strasser]

Hi Nicolas,

Nicolas George wrote:
> Le septidi 7 ventôse, an CCXX, Alexander Strasser a écrit :
> >   This function takes a string and tokenizes it into pairs. The
> > caller will be called back for each pair.
> 
> It this was Caml, I would clap with both hands (well, clapping with only one
> hand is awkward anyway),

  lol :D

> but in C, this kind of API, while theoretically
> capable of implementing anything, is often very impractical for most tasks.
> And since it does not allow to avoid mallocs anyway, I would rather like to
> propose this one: (see below).

  I did not yet fully grasp how you do it, but it looks interesting I
will delve into the code at some later point in time. I value your
participation and apologise that I don't have time to look at your
patch closely before Thursday.

  Now to your statement; my implementation tries to rather not use too
much memory while yours uses the string's size - escapes + additional
storage for the pointers. But I agree with you that neither of our
implementations should be used for very large strings, mine is even
slightly at disadvantage in its current form because it might exhibit
bad worst case performance.

> Compared to yours, it returns all key-value pairs in a single array. A
> significant difference is that if a syntax error occurs late in the string,
> your version calls the callback for the early pairs while mine returns only
> an error.

  I see. Knowing about errors before hand might result in simpler
client code. I don't think it might matter that much usually, but
will probably be more easy to use in some cases. Also if I am not
mistaken my version could be changed to do a pure syntax check if
the user passes in e.g. a NULL callback.

> There are a few open questions:
> 
> - Do we accept unescaped '=' in the value string? Yours does not, mine does;
>   and I believe the answer should be yes.

  Probably yes, except if comp_delim = pair_delim. But as, I think, the
latter is supported by none of our implementations we should probably
not allow it anyway.

> - Do we accept keys without '=' and value? It could return vale as NULL.

  This would also conflict if we wanted to support comp_delim = pair_delim.
As I think we might not want to support that anyway it might still be better
be better to make it configurable or leave it out completely. With my
interface it could handled by the callback, in yours passing an additional
flags parameter could do.

> - Do we accept empty keys?

  Same as above also note that I did intentionally not mention key-value
pairs. I wanted to introduce a more generic functionality that handles
extracting a sequence of pairs from a string while at the same time
would allow to solve Andrey's problem conveniently. I also conisdered
adding a slightly more tuned/sophisticated callback as in my avdict
example, so users of lavu could fill a dict easily without having to
implement any callback at all.

  [...]

  I will try out your implementation as soon as time permits. At the
very moment I feel a bit like tending towards your solution. Also it
would be interesting to hear if Andrey has any preferences. I wonder
if he is listening...

Thank you for both your comments and your work,
  Alexander