While libm can be linked on generating final executable, it's still
preferred to link it against the library itself to better represent the
dependency hierarchy.

Added support for MSVC and (rather coincidentally) C++98 by replacing
the decltype keyword and removing the corresponding preprocessor
checks.

To prevent warnings in modern compilers

Example (starting in the source directory):
  $ mkdir build
  $ cd build
  $ ../configure
  $ make

Make complains:
 ar rcs libjsonparser.a json.o
 ar: json.o: No such file or directory
 make: *** [Makefile:29: libjsonparser.a] Error 1

json.h: <inttypes.h> → <stdint.h>
int64_t is defined in <stdint.h>, no need for the full <inttypes.h>

json.h: <stdlib.h> → <stddef.h>
<stddef.h> is enough to define size_t

json.c: <stdlib.h>
Now that <stdlib.h> has been removed from json.h, add it to json.c for
malloc()/calloc() and free()

…whitespaces

Get rid of trailing whitespaces

…signed_int

cur_line and cur_col are unsigned

Added fall through markers

example: fix typo

Remove dependency on decltype in C++ API

Add LDFLAGS support and missing lm option

Import of 'sys' is not used.

https://lgtm.com/rules/6770079/

Avoid the following linking error on Ubuntu 20.04:
/usr/bin/ld: /tmp/ccPCOj2I.o: relocation R_X86_64_PC32 against symbole `json_value_free_ex' can not be used when making a shared object; recompilez avec -fPIC

…ser#113, json-parser#114

Reorder header files as suggested here:
	https://stackoverflow.com/questions/2762568/c-c-include-header-file-order
	https://softwareengineering.stackexchange.com/questions/325549/c-header-file-order

Change order of #include

The counterpart to json-parser/json-builder#17

Fixes json-parser#49

Made a slight adjustment to keep the "ANSI C" text in case people still search for it that way, even if it is erroneous and/or ambiguous.

The reverted solution was a workaround. See comments for the pull request at:
<json-parser#114 (comment)>
<json-parser#114 (comment)>

This reverts commit 240bb6d.

The object files are not in use or even created.  The source files are
used directly in the linking process, thereby ignoring the CFLAGS variable.

This is according to a comment given in pull request number 114.
<json-parser#114 (comment)>

Type char is known to be compatible with sprintf().
Besides the user-provided 'error_buf' is also of type char.

CID 308347: Assignment of overlapping memory (OVERLAPPING_COPY)
overlapping_assignment: Assigning top->u.integer to top->u.dbl,
which have overlapping memory locations and different types.

…-parser#128

CID 308347: Assignment of overlapping memory (OVERLAPPING_COPY)
overlapping_assignment: Assigning top->u.integer to top->u.dbl,
which have overlapping memory locations and different types.

File test.py is executable in Git, yet does not start with "#!".

…-parser#145

Forgot to merge this with the others...

That's the standard over all the C standard library.

Either it has been defined explictly, or we attempt to calculate it
using the method reverted by fcfa748.

See discussion in json-parser#84 and json-parser#102.

Fix valid-0013.json added by fab533e (json-parser#125)

It looks like a bad idea to compare apply to a double operators ++ and --,
or to compare to integers.

…-parser#144