On Sat, Sep 1, 2018 at 1:49 PM Graham Leggett <minf...@sharp.fm> wrote:
>
> On 01 Sep 2018, at 13:13, Yann Ylavic <ylavic....@gmail.com> wrote:
>
> > So how about the attached patch too, allowing for case sensitive
> > apr_tables? :p
> > apr_json could then use apr_table_make_ex()…
>
> I like the idea of a case sensitive apr_table, it’s something that would have
> been useful to me in the past.
Yeah, quite tangential to JSON but indeed useful, I'll commit it
independently if no objection arises.
>
> Using it in the JSON code I’m still not keen on, as we need the hard security
> guarantees of the apr_hash method signature, which has just one mode of
> operation.
I'm not sure what you mean by the "hard security guarantees of the
apr_hash method signature", for me the only hard guarantee of
apr_hash_t is to not lose data, but that's also a guarantee of
apr_table :)
Speaking of JSON, the downside of apr_hash are no-doublons and the
need for klen all over the place, so for me the right structure is
(caseless-)apr_table.
> We’re also still forced to unnecessarily strndup all our keys on the way in
> to make them NUL terminated.
No we don't, in my patch apr_json_string_create() does apr_strmemdup()
only if the given len != APR_JSON_VALUE_STRING (which makes sense both
to make sure that the given string is NUL-terminated and to provide a
way to duplicate it if it's not already or the scope doesn't fit).
Then C string key version of apr_json_object_{set,add}() uses
APR_JSON_VALUE_STRING to build the json string key and
apr_table_setn/addn() to fill the table, so no duplication occurs by
default.
The way to duplicate the key for the user would be to
apr_json_object_{set,add}_ex(apr_json_string_create(key, strlen(key),
value, ...) explicitely, but that's not the "default" API.
Otherwise everything should work as before, and I like the _set/add()
semantics (borrowed from apr_table) nice w.r.t. doublons.
Regards,
Yann.
