Open dmarks-ls opened 7 years ago
These issues have cropped up in the past - what helps to solve it is knowing, for all of the basic types, both the sizes used by the compiler, as well as testing std::is_equal against long. We have to try and come up with a solution that is unambiguous for everyone.
Any progress on this one? I use cereal as a dependency in a publicly accessible project, and modifying vendor library is not an option there.
I'm running Cereal 1.2.2 on an NXP Kinetis K64 microcontroller (Cortex-M4) using Kinetis Design Studio 3 and KSDK v2.1. I've got it working great; I'm using it to parse and emit commands and responses for a JSON-formatted protocol.
I've found that there are only two modifications I have to make to Cereal to get it to work in my build and execution environment. One involves the chunk allocator, which I'll save for a different thread. The other involves the
JSONOutputArchive
class, specifically thesaveValue()
overloads.The crux of the issue is this: in the KDS 3 build environment,
int32_t
has been defined aslong
, anduint32_t
isunsigned long
. This annoys me to no end because I have to change all my print specifiers from%d
to%ld
to avoid warnings, etc. Of course,size_t
is justunsigned int
, souint32_t
andsize_t
are not identical types. Grr.Anyway, here's what happens on my platform if I compile Cereal as-is (output edited for clarity):
The method
saveLong()
is casting the (verified by traits) signed 32-bit value to anint32_t
, and then passing that tosaveValue()
. But sinceint32_t
islong
, none of thesaveValue()
methods match, so C++ can't decide which overload to use.My workaround for this has been to add a couple more overloads:
However, I don't think this holds up if compiling on an architecture where
sizeof(int) != sizeof(long)
, e.g. iflong
is 8 bytes. I tried modifying thestatic_cast<>
invocations insaveLong()
to callint
andunsigned int
instead ofstd::int32_t
andstd::uint32_t
, but that only fixes the internal calls tosaveLong()
; application calls tosaveValue()
will still fail if passed along
type.So... what's the correct/best way to fix this? How can I avoid having to edit
cereal/archives/json.hpp
every time I import cereal into a Kinetis project? I mean, it's not a big deal to add the two extra overloads above, but editing library code is always less than ideal. Thanks.