Hmm, well, good to know it doesn't compile on Windows (I should've tested that)

@hawicz This now compiles properly and is ready for review

First of all, thank you for working on this. I don't have a whole lot of time right now, but the things that I noticed so far from glancing at the diffs are:

• This changes API of json_c_shallow_copy_default and json_object_object_foreach, which means it would require a major version bump. Can we avoid that?
• New functions that don't follow the naming pattern of preexisting ones, like json_key_size(), etc... would be better if they were named more json-c specific. e.g. maybe json_c_key_size()?
• It seems like a few of the new API functions could be consolidated, and just provide _key versions that take a json_key. (and perhaps provide a "json_c_key_make_temp(const char *, ssize_t)")
• However, I'm a bit wary of creating a json-c specific length-based buffer, i.e. struct json_key. If there's no good pre-existing, widely used similar structure to use, then ok, but I suspect we might be able to make a better choice here.

I'm planning on taking a more in-depth look at this soon, so I'll probably have a few more things to comment on.

I started gathering some notes about possible buffer implementations to use over at https://github.com/json-c/json-c/wiki/Proposal:-Use-sized-buffers-instead-of-asciiz-strings
Given what I've found so far, there doesn't seem to be anything exactly like what I'm looking for. However, if we're going with json-c specific code, it just occurred to me that the existing arraylist code already implements a fair amount of the buffer handling, so maybe we could just abuse/extend that slightly.

Also, the naming of the new functions, _key isn't so great either, because "key" doesn't seem to describe very well what makes those different.

I'm not a huge fan of _key either, but I didn't really know what to name them with. Also, for the struct json_key, would it be a good idea to modify struct json_string so they can both share some common items? Since that's basically what keys are is just strings.

Apologies for the delay, I just had a concern, am I free to modify linkhash.h? I currently have in order to actually be able to meaningfully be able to hash and compare keys with null characters. If the major version is being increased, can we drop linkhash.h as a publicly includeable file? Seems like that'd make it easier to make changes in the future, too.

I think it would be possible to get away without modifying either that or json_c_visit_userfunc (in json_visit.h), but it would certainly be really kludgy, involving ensuring the key always contained the data inline const char * and prepending data before each of the pointers passed to those functions? I'm not sure how far you'd be willing to go to maintain backward compatibility, though.

Though, I'd already be modifying json_object_deep_copy_recursive with your suggestion, so I think it'd need to bump the major version number. I think all the changes to avoid a major version bump would be difficult to maintain.