Since C is statically typed and JSON is not, and any JSON element can be a null, a number, a string, a boolean, an object, or an array, you basically have to do it as "a rip off the OOP way". Create a record type that represents a JSON value, and has a member that's a tag indicating which type of JSON value it is, and then create "subclasses" that build on this record type. To represent JSON well in C, you basically have to recreate OOP and polymorphism.

Anything that uses a JSON value will have to take a pointer to the base record type. Remember that objects are always reference types, poor C++ language design choices notwithstanding, because otherwise it screws up polymorphism, and you require polymorphism to do this right. When you find out what kind of "subclass" you're actually working with, (by checking the tag member,) you can cast your JSON Value pointer to the appropriate subclass type pointer to access the rest of the record.

Json isn't a huge language to start with, so libraries for it are likely to be small(er than Xml libraries, at least).

There are a whole ton of C libraries linked at Json.org. Maybe one of them will work well for you.

Header

In C, all enum names share the same namespace with each other (and with things like variable names). It's therefore a good idea to try to reduce the risk that they'll collide.

Your enum json_value_type names have the prefix TYPE_, which is pretty generic. Some other library might try to use the same name. I'd suggest changing that prefix to, say, JSON_.

Also, you don't seem to be using TYPE_KEY for anything. Just remove it.

Implementation

As Roland Illig notes, the arguments to iscntrl() and isspace() in your skip_whitespace() function should be cast to unsigned char to avoid sign extension.

Alternatively, and more closely following the JSON spec, you could rewrite this function simply as:

static void skip_whitespace(const char** cursor)
{
    while (**cursor == '\t' || **cursor == '\r' ||
           **cursor == '\n' || **cursor == ' ') ++(*cursor);
}

A lot of your static helper functions do non-trivial combinations of things, and lack any comment explaining what they do. One or two comment lines before each function could help readability a lot.

In particular, your has_char() function does a bunch of different things:

1. It skips whitespace.
2. It checks for the presence of a certain character in the input.
3. If the character is found, it automatically skips it.

Only #2 is obviously implied by the function name; the others are unexpected side effects, and should at least be clearly documented.

Actually, it seems to me that it might be better to remove the call to skip_whitespace() from has_char(), and just let the caller explicitly skip whitespace before calling it if needed. In many cases your code already does that, making the duplicate skip redundant.

Also, to make effect #3 less surprising to the reader, it might be a good idea to rename that function to something a bit more active like, say, read_char().

At the end of json_parse_object(), you have:

    return success;
    return 1;
}

Surely that's redundant. Just get rid of the return 1;.

Also, it looks like you're using the generic json_parse_value() function to parse object keys, and don't test to make sure that they're strings. This allows some invalid JSON to get through your parser. I'd suggest either adding a explicit type check or splitting your string parsing code into a separate function (as described below) and calling it directly from json_parse_object().

At the top of json_parse_array(), you have:

if (**cursor == ']') {
    ++(*cursor);
    return success;
}
while (success) {

You could rewrite that the same way as you do in json_parse_object():

while (success && !has_char(']')) {

(Only, you know, I still think the name read_char() would be better.)

Also, for some reason, your json_parse_array() seems to expect the caller to initialize the parent struct, while json_parse_object() does it automatically. AFAICT there's no reason for the inconsistency, so you could and probably should just make both functions work the same way.

Your json_is_literal() function is not marked as static, even though it doesn't appear in the header. Like is_char(), I'd also prefer to rename it to something more active, like json_read_literal() or just read_literal(), to make it clearer that it automatically advances the cursor on a successful match.

(Also note that, as written, this function does not check that the literal in the input actually ends where it's supposed to. For example, it would successfully match the input nullnullnull against null. I don't think that's an actual bug, since the only valid literals in JSON are true, false and null, none of which are prefixes of each other, and since two literals cannot appear consecutively in valid JSON without some other token in between. But it's definitely at least worth noting in a comment.)

You might also want to explicitly mark some of your static helper functions as inline to give the compiler a hint that it should try to merge them into the calling code. I'd suggest doing that at least for skip_whitespace(), has_char() and json_is_literal().

Since your json_value_to_X() accessor functions all consist of nothing but an assert() and a pointer dereference, you should also consider moving their implementations into json.h and marking them as static inline. This would allow the compiler to inline them into the calling code even in other .c files, and possibly to optimize away the assert() if the calling code already checks the type anyway.

In your main json_parse() function, you might want to explicitly check that there's nothing but whitespace left in the input after the root value has been parsed.

String parsing

Your string parsing code in json_parse_value() is broken, since it doesn't handle backslash escapes. For example, it fails on the following valid JSON input:

"I say: \"Hello, World!\""

You may want to add that as a test case.

You should also test that your code correctly handles other backslash escape sequences like \b, \f, \n, \r, \t, \/ and especially \\ and \unnnn. Here's few more test cases for those:

"\"\b\f\n\r\t\/\\"
"void main(void) {\r\n\tprintf(\"I say: \\\"Hello, World!\\\"\\n\");\r\n}"
"\u0048\u0065\u006C\u006C\u006F\u002C\u0020\u0057\u006F\u0072\u006C\u0064\u0021"
"\u3053\u3093\u306B\u3061\u306F\u4E16\u754C"

Since JSON strings can contain arbitrary Unicode characters, you'll need to decide how to handle them. Probably the simplest choice would be to declare your input and output to be in UTF-8 (or perhaps WTF-8) and to convert \unnnn escapes into UTF-8 byte sequences (and, optionally, vice versa). Note that, since you're using null-terminated strings, you may prefer to decode \u0000 into the overlong encoding "\xC0\x80" instead of a null byte.

For the sake of keeping the main json_parse_value() function readable, I would strongly recommend splitting the string parsing code into a separate helper function. Especially since making it handle backslash escapes correctly will complicate it considerably.

One of the complications is that you won't actually know how long the string will be until you've parsed it. One way to deal with that would be to dynamically grow the allocated output string with realloc(), e.g. like this:

// resize output buffer *buffer to new_size bytes
// return 1 on success, 0 on failure
static int resize_buffer(char** buffer, size_t new_size) {
    char *new_buffer = realloc(*buffer, new_size);
    if (new_buffer) {
        *buffer = new_buffer;
        return 1;
    }
    else return 0;
}

// parse a JSON string value
// expects the cursor to point after the initial double quote
// return 1 on success, 0 on failure
static int json_parse_string(const char** cursor, json_value* parent) {
    int success = 1;

    size_t length = 0, allocated = 8;  // start with an 8-byte buffer 
    char *new_string = malloc(allocated);
    if (!new_string) return 0;

    while (success && **cursor != '"') {
        if (**cursor == '\0') {
            success = 0;  // unterminated string
        }
        // we're going to need at least one more byte of space
        while (success && length + 1 > allocated) {
             success = resize_buffer(&new_string, allocated *= 2);
        }
        if (!success) break;
        if (**cursor != '\\') {
             new_string[length++] = **cursor;  // just copy normal bytes to output
             ++(*cursor);
        }
        else switch ((*cursor)[1]) {
            case '\\':new_string[length++] = '\\'; *cursor += 2; break;
            case '/': new_string[length++] = '/';  *cursor += 2; break;
            case '"': new_string[length++] = '"';  *cursor += 2; break;
            case 'b': new_string[length++] = '\b'; *cursor += 2; break;
            case 'f': new_string[length++] = '\f'; *cursor += 2; break;
            case 'n': new_string[length++] = '\n'; *cursor += 2; break;
            case 'r': new_string[length++] = '\r'; *cursor += 2; break;
            case 't': new_string[length++] = '\t'; *cursor += 2; break;
            case 'u':
                // TODO: handle Unicode escapes! (decode to UTF-8?)
                // note that this may require extending the buffer further
            default:
                success = 0; break;  // invalid escape sequence
        }
    }
    success = success && resize_buffer(&new_string, length+1);
    if (!success) { 
        free(new_string);
        return 0;
    }
    new_string[length] = '\0';
    parent->type = TYPE_STRING;
    parent->value.string = new_string;
    ++(*cursor);  // move cursor after final double quote
    return 1;
}

An alternative solution would be to run two parsing passes over the input: one just to determine the length of the output string, and another to actually decode it. This would be most easily done something like this:

static int json_parse_string(const char** cursor, json_value* parent) {
    char *tmp_cursor = *cursor;

    size_t length = (size_t)-1;
    if (!json_string_helper(&tmp_cursor, &length, NULL)) return 0;

    char *new_string = malloc(length);
    if (!new_string) return 0;

    if (!json_string_helper(&tmp_cursor, &length, new_string)) {
        free(new_string);
        return 0;
    }
    parent->type = TYPE_STRING;
    parent->value.string = new_string;
    *cursor = tmp_cursor;
    return 1;
}

where the helper function:

static int json_parse_helper(const char** cursor, size_t* length, char* new_string) {
    // ...
}

parses a JSON string of at most *length bytes into new_string and writes the actual length of the parsed string into *length, or, if new_string == NULL, just determines the length of the string without actually storing the decoded output anywhere.

Number parsing

Your current json_parse_value() implementation treats numbers as the default case, and simply feeds anything that doesn't being with ", [, {, n, t or f into the C standard library function strtod().

Since strtod() accepts a superset of valid JSON number literals, this should work, but can make your code sometimes accept invalid JSON as valid. For example, your code will accept +nan, -nan, +inf and -inf as valid numbers, and will also accept hexadecimal notation like 0xABC123. Also, as the strtod() documentation linked above notes:

In a locale other than the standard "C" or "POSIX" locales, this function may recognize additional locale-dependent syntax.

If you want to be stricter, you might want to explicitly validate anything that looks like a number against the JSON grammar before passing it to strtod().

Also note that strtod() may set errno e.g. if the input number is outside the range of a double. You probably should be checking for this.

Testing

I have not looked at your tests in detail, but it's great to see that you have them (even if, as noted above, their coverage could be improved).

Personally, though, I'd prefer to move the tests out of the implementation into a separate source file. This does have both advantages and disadvantages:

• The main disadvantage is that you can no longer directly test static helper functions. However, given that your public API looks clean and comprehensive, and doesn't suffer from any "hidden state" issues that would complicate testing, you should be able to achieve good test coverage even just through the API.
• The main advantage (besides a clean separation between implementation and testing code) is that your tests will automatically test the public API. In particular, any problems with the json.h header will show up in your tests. Also, doing your tests via the API helps you ensure that your API really is sufficiently complete and flexible for general use.

If you really still want to directly test your static functions, you could always add a preprocessor flag that optionally exposes them for testing, either via simple wrappers or just by removing the static keyword from their definitions.

Ps. I did notice that your json_test_value_number() test is failing for me (GCC 5.4.0, i386 arch), presumably because the number 23.4 is not exactly representable in floating point. Changing it to 23.5 makes the test pass.

What you have is reasonable, although an alternative might be some sort of result builder:

char buff[256] = { 0 }

jsonObjectOpen(buff);
jsonObjectInteger(buff,"minHour", minHour);
jsonObjectInteger(buff,"maxHour", maxHour);
jsonObjectClose(buff);

Basically each function is appending the necessary json elements to the buffer, and you'd need to implement functions for each data type (string, int, float), and of course, make sure you use the in the correct order.

I don't think this is more succinct, but if you are doing it more than a few times, especially for more complex structures, you might find it more readible and maintainable.

It's entirely possible there is an existing library that will help with this type of approach, also being mindful of ensuring that the buffer space isn't exceeded during the building process.

In other languages that have type detection, this is a lot easier, and I supposed you could always have a single function that takes a void pointer and a 'type' enum, but that could be more error prone for the sake of a marginally simpler API.