macOS's newlocale() does not follow POSIX specification - it doesn't
reuse the passed locale_t, causing ~1,472 bytes leak per json_tokener_parse() call.
This is the same issue as #668 (FreeBSD). The existing workaround works,
but macOS was not auto-detected.
Tested with AddressSanitizer: leak drops from 1,472,000 bytes to ~120 bytes
(system init only).
Fixes https://github.com/json-c/json-c/issues/909
When ssize_t is defined as a macro, typically through a package's config.h file,
the installed json*.h files must not attempt to define ssize_t via typedef.
That include line wasn't valid code, so that resulted in:
Checking for size of "size_t" : -1
And later on:
json-c/json_patch.c:28:2: error: #error Unable to determine size of size_t
All of these are effectively the same. No point in duplicating it
everywhere.
Remove prefix from has_function. Apparently having the prefix in there
changes behavior.
Also fix an error on MinGW where SSIZE_T_MAX is undefined.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Windows was failing tests due to how the Windows API works with some of the calls used.
When opening and reading a file O_BINARY is needed otherwise it fails for size checks. This is due to how Windows handles newlines and counts between text and binary mode file reads.
Also fixed is the test for /dev/null.
In Windows, this fails, but crashes due to a missing return statement when it cannot open this file.
I also tried telling windows to open the special file NUL, however that leads to a CRT crash later in the test that cannot be stopped and will always fail. Rather than fail a test that Windows will always fail, it has been disabled in that specific case.
Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
Adding meson build files for json-c that work similarly to the cmake build files.
Where it made sense, I reused existing cmake .h.in files or generated entirely from meson.
All tests were done with GCC and Clang in ubuntu 24.04, Windows using MSVC 2022 and Clang-cl from llvm's repo using version 21.1.3
Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
Clang-cl will fail to build and produce warnings about redefining existing symbols, mostly for float.h and math.h compatibility.
To resolve this, this moves the clang-cl detection earlier in the CMakeLists.txt so that CLANG_CL can be checked properly where there is an existing MSVC workaround for these symbols.
This resolves the build using the latest clang-cl from the LLVM clang repo as well as clang-cl that can be installed with MSVC 2022.
Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
