The definition of typedef int32 bool in our splinterdb/platform_linux/public_platform.h caused me a very basic integration issue with other s/w code which links with SplinterDB library. The problem is that the \<some other> code defines this as unsigned char, which is 1-byte. Splinter's definition of bool as int32 throws-off some structure layouts.
Specifically, see the layout of public splinterdb_config{} as of SHA d9fcc407 in /main, defined in include/splinterdb/platform_linux/public_platform.h:
Due to the differing definitions of typedef bool, the offset of fields past the 1st instance of bool (i.e. L50 bool cache_use_stats) will differ in the .o-s compiled into the library and in the objects for the \<other code> base.
This makes the system unstable.
Asking internally with SplinterDB core-dev team, we agreed to stabilize on 1-byte bool fields.
Longer-term may be the better way would be to #include <stdbool.h> but that's not being followed through right now.
The definition of
typedef int32 bool
in oursplinterdb/platform_linux/public_platform.h
caused me a very basic integration issue with other s/w code which links with SplinterDB library. The problem is that the \<some other> code defines this asunsigned char
, which is 1-byte. Splinter's definition ofbool
asint32
throws-off some structure layouts.Specifically, see the layout of public
splinterdb_config{}
as of SHA d9fcc407 in/main
, defined ininclude/splinterdb/platform_linux/public_platform.h
:Due to the differing definitions of
typedef bool
, the offset of fields past the 1st instance ofbool
(i.e. L50bool cache_use_stats
) will differ in the.o
-s compiled into the library and in the objects for the \<other code> base.This makes the system unstable.
Asking internally with SplinterDB core-dev team, we agreed to stabilize on 1-byte
bool
fields.Longer-term may be the better way would be to
#include <stdbool.h>
but that's not being followed through right now.