Max Bruckner

That sounds like a really good idea, but I thought that it is undefined behavior to use an enum with another than the predefined values. Let me check if that...

Renaming it to `typeinfo` instead of `type` might actually be a good idea, because it not only stores the type, but also `cJSON_IsReference` and `cJSON_IsConst`. Another possible solution: Make it...

Using a bitfield fixes `->type == cJSON_XXXX` if a node is a reference or contains a constant string. So it is not necessary to use `& 0xFF` anymore when comparing.

Defining the types as `const` instead of `#define` doesn't work because it is not supported in switch case.

Well, let's change all of the bit fields from `int` to `unsigned int`. [For this reason!](https://stackoverflow.com/questions/40685524/is-this-bit-field-of-size-one-actually-overflowing-when-assigning-1)

In order to be fully JSON conformant, cJSON needs to support `'\0'` in strings. This requires storing the length for `name` and `string`. Also it should be possible to use...

I thought of a better idea than using a union. Since `cJSON` structs are not stored in arrays, a dynamicly sized struct can be used. There can be a base...

Also note that I added the possibility of having `int` or `long int` numbers, since there have been many requests to support scenarios where `double` is not available.

I did give up maintaining it because of burnout a long time ago, but I've seen @Alanscut do some maintenance work since then.

Also there are some files that look like they are used for C++ code generation. That's probably an issue as well.