Introduce json_object_new_string_{ext,noalloc}().

[besser82]

This PR is basically a working version of #476.

---

The json_object_new_string_ext() function helps to reduce code duplication, as it can be easily extended for different ways how a new json string-object will be created from a given string buffer.

---

On some low memory systems, calling malloc (by the use of strdup) may cause memory fragmentation, which eventually results in out of memory situations.

Using the json_object_new_string_noalloc() function can help to solve such issues.

---

test_string_noalloc is a short test to make sure the json_object_new_string_noalloc() function works as expected.

[coveralls]

Coverage increased (+0.2%) to 87.218% when pulling 0e43aab on besser82:topic/besser82/json_object_new_string_ext into fa6a7dc on json-c:master.

[hawicz]

We can't guarantee that calling free() will be valid. Just because you don't want to strdup the string doesn't mean that it's memory from malloc. It might be global memory, or local variables that you happen to know won't go out of scope before the jso does, or a chunk of memory from an allocator other than malloc.

[hawicz]

To actually support this, we'll need a different way to indicate whether the string is stored directly or not. Perhaps, since c_string.len is signed, we could use negative lengths to mean it's stored directly? hmm...

[besser82]

We can't guarantee that calling free() will be valid. Just because you don't want to strdup the string doesn't mean that it's memory from malloc. It might be global memory, or local variables that you happen to know won't go out of scope before the jso does, or a chunk of memory from an allocator other than malloc.

Then we would hit the same problem when the jso gets destroyed, which would call free() on the string buffer through json_object_string_delete() as well…

[besser82]

I've marked all changes, that I have made localy, as resolved to keep track of them. I'll push them as soon as we have found a solution here.

[hawicz]

Well sure, so the code in json_object_string_delete would need to do if (jso->o.c_string.len < 0) instead of if (jso->o.c_string.len >= LEN_DIRECT_STRING_DATA), and every other place that currently references LEN_DIRECT_STRING_DATA would need some kind of change. There are 7 of those total.

[besser82]

Wouldn't it be better to have a parameter which specifies a func ptr to the free() function that corresponds to the undelying memory-allocator? And maybe NULL to use the system default free()? For stack-allocated objects we could offer a noop-function as well…

That seems better than relying on users to specify a negative value for the buffer length…

[hawicz]

You misunderstand me. I'm not saying that the caller would specify a negative value, it would be the json-c code that would use a negative value if it decides to store the string directly.

[hawicz]

...and in the no-strdup case we would never copy the string into direct storage.

[hawicz]

i.e.:

...
if ( !(flags & JSON_C_NEW_STRING_NO_STRDUP) &&
     (len < LEN_DIRECT_STRING_DATA))
{
    ...
    jso->o.c_string.len = -len;
    return jso;
}
...

[hawicz]

Any interest in revisiting this? If so, feel free to re-open this PR or create a new one against the most recent code (ideally with previous comments addressed).