Strict checking of endian-specific types mean that types that have a
fixed endianness in the data representation of the value are now defined
as complex types, enabling the compiler to catch mixed usage of these
types with native-endian types. This allows us to catch most issues
relating to usage on big-endian systems since we cannot anymore assign a
fixed-endian value to a native-endian variable and vice-versa without a
compiler error.
The downside is that we aren't able to apply simple binary operators to
the fixed-endian types anymore since they are complex... so all
combining fixed-endian constants and values with |, &, etc. and
comparison with ==, !=, <=, etc. must be replaced with a macro which
unpacks the wrapped value and performs the operation. Lots of changes,
lots of work but in the interest of good code quality it's justified.
On-disk struct definitions used native types (u16/u32/u64/s16/s32/s64),
which doesn't say anything about the intended interpretation of the
data. The intention of having little-endian-specific types and
big-endian-specific types must have been to clarify interpretation of
data and intentions in the code. Therefore it seems reasonable to use
these types in struct definitions to clarify what data represention is
used to encode field data.
Because some struct members in layout.h are big-endian, this change also
means moving the duplicated definitions for big-endian byteswapping
macros and big-endian types found in acls.h and security.h to the
appropriate locations in endians.h and types.h respectively in order to
make them available for the struct definitions in layout.h.
fuse-lite announces a FUSE_VERSION which may not always match the exact
capabilities of the library. Hence we add a special case for 'ioctl',
which we know exists in fuse-lite regardless of the version number
published.
The capability actually appeared in FUSE 2.9, not 2.8. However in order
to maintain similarity to earlier #ifdef:s, we simpy check if
FUSE_CAP_IOCTL_DIR is defined rather than checking the FUSE version.
The variable 'res' was never initialized if the #ifdef condition
'!KERNELPERMS | (POSIXACLS & !KERNELACLS)' evaluated to true and there
was an error allocating memory for 'value'.
Erik Larsson