I believe there's no way to define a 64-bit integer in C89, at least not in a portable way.

In the same way, INT64_MAX is not defined in C89 (and INT32_MAX shouldn't be defined either). But that issue is not on me.

Yes, I was aware of that. I think people on systems that only support C89 won't really be able to use a 64-bit integer much anyway, or they can define json_int_t themselves, so using just long by default under C89 should suffice. Some systems/compilers actually make long 64-bit anyway. We may also be able to convert the macro from #102 to work with a passed in type as a parameter so it can be used in more places.

Actually, I believe #102 is not ANSI C either, because of 1UL. It may well be impossible to find the size of json_int_t in pure C89. But then it's usually already defined elsewhere, so let's not reinvent the wheel.

This change is a bit invasive for a patch release such as 1.1.1: a new JSON_INT_MAX macro is defined in json.h. But then there's no good way to fix this in a simpler way. Perhaps leave this for 1.2.0? Perhaps release 1.2.0?

What was wrong with the previous definition of JSON_INT_MAX reverted by fcfa748? It's not clear to me.

static const json_int_t JSON_INT_MAX = (((unsigned json_int_t)0 - (unsigned json_int_t)1) / (unsigned json_int_t)2);

Perhaps casting back to signed?

static const json_int_t JSON_INT_MAX = (json_int_t)(((unsigned json_int_t)0 - (unsigned json_int_t)1) / (unsigned json_int_t)2);

Also, I would keep int64_t for 1.1.1, and switch to int_fast64_t in 1.2.0.

What was wrong with the previous definition [...]?

It's unclear to me too. I think for simple usage we can keep the automatic calculation with the new version you propose, and just have the documentation stipulate that json_int_t must be defined as a primitive integer type without signed or unsigned included, and otherwise the user must additionally define JSON_INT_MAX. I'm not sure how useful it is to have in the header as opposed to the source file though. These changes look good so far though, I just think we should keep the automatic calculation for simple usage scenarios.

Everything happens in the header because I need to know whether:

• json_int_t has been defined explicitly by the end-user, in which case I have no knowledge of its exact type and if JSON_INT_MAX has not been defined, I can either #error out or attempt the automatic calculation of JSON_INT_MAX,
• or json_int_t has been defined automatically by the header, in which case JSON_INT_MAX must have been defined automatically too.

To move the above logic to json.c, I would need a two-step process and two macro variables, such as json_int_t (a macro) / internal_json_int_t (a typedef ?), just like JSON_INT_MAX /TYPED_JSON_INT_MAX.

Anyway, I can switch to the automatic calculation of JSON_INT_MAX in json.c if it has not been already defined.

Note that we need additional information on how to print json_int_t:

• "%I64d" for __int64 on Windows (Format specification syntax: printf and wprintf functions)
• "%" PRId64 for int64_t
• "%l" for long

I suggest we leave that for 1.2.0...

I could also define a private JSON__JSON_INT_T_USER_DEFINED macro in json.h:

#ifndef json_int_t
   #if defined(_MSC_VER)
      #define json_int_t __int64
   #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
      /* C99 */
      #include <stdint.h>
      #define json_int_t int64_t
   #else
      /* C89 */
      #define json_int_t long
   #endif
#else
   #define JSON__JSON_INT_T_USER_DEFINED 1
#endif

and do the rest in json.c:

#ifndef JSON__JSON_INT_T_USER_DEFINED
   #if defined(_MSC_VER)
      /* https://docs.microsoft.com/en-us/cpp/cpp/data-type-ranges */
      #define JSON_INT_MAX 9223372036854775807LL
   #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
      /* C99 */
      #define JSON_INT_MAX INT64_MAX
   #else
      /* C89 */
      #include <limits.h>
      #define JSON_INT_MAX LONG_MAX
   #endif
#endif
[...]
#ifndef JSON_INT_MAX
static const json_int_t TYPED_JSON_INT_MAX = (json_int_t)(((unsigned json_int_t)0 - (unsigned json_int_t)1) / (unsigned json_int_t)2);
#else
static const json_int_t TYPED_JSON_INT_MAX = JSON_INT_MAX;
#endif

I could even add printing formats, as suggested in #115 (comment).

I have added a new version, as explained above:

• Macro JSON__USER_DEFINED_JSON_INT_T is set when users define json_int_t explicitly.
• Use int_fast64_t instead of int64_t, that's the right thing to do and doesn't break the API.
• If JSON__USER_DEFINED_JSON_INT_T is defined, hope that users have defined JSON_INT_MAX too, and if not, attempt to calculate JSON_INT_MAX.

Identifiers should not begin with underscores, but double underscores within the identifier are OK in C. Only in C++ are consecutive underscores reserved for the implementation. Technically, this is a C program. It could be compiled by a C++ compiler, but it's still C, so I feel the double underscores are OK.

That said, I had added the double underscore because JSON__USER_DEFINED_JSON_INT_T was indeed long and complex. Your suggestion to switch to JSON_INT_T_OVERRIDDEN removes the need for it.