On 31 Aug 2018, at 14:26, Yann Ylavic <ylavic....@gmail.com> wrote: > I wonder if we shouldn't change the apr_hash_t (currently used to > handle JSON objects) to an apr_table_t, such that key doublons are not > an issue (this isn't one in JSON specification AFAICT). > > Then we could get rid of 'klen' handling in several places (NUL > terminated string is fine for keys IMHO, the question is more about > strdup or not) while APR_JSON_FLAGS_STRICT would still do its job for > overlays (and could be extended to apr_json_object_set w/ something > like APR_JSON_FLAGS_MULTI, mutually exclusive).
I wondered about this for a while, I’m keen to keep the code as it is, to follow the ap_hash_t interface with key and key length as closely as possible. When decoding JSON, the original strings are referenced in place, and this saves both time and memory. If the strings became NUL terminated we would have to strndup each one, which would slow us down and almost double the memory footprint. Regards, Graham —
