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

> 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
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.


Reply via email to