-
Notifications
You must be signed in to change notification settings - Fork 84
Description
Hello,
often the mistake is made (happened to me too) to consider only 2 cases when checking the endianess, eg:
struct foo
{
#if defined(BOOST_ENDIAN_LITTLE_BYTE_AVAILABLE)
uint32_t a : 16;
uint32_t b : 16;
#else
uint32_t b : 16;
uint32_t a : 16;
#endif
};
because the else branch is not necessarily BOOST_ENDIAN_BIG_BYTE_AVAILABLE. More correctly, this example must read:
struct foo
{
#if defined(BOOST_ENDIAN_LITTLE_BYTE_AVAILABLE)
uint32_t a : 16;
uint32_t b : 16;
#elif defined(BOOST_ENDIAN_BIG_BYTE_AVAILABLE)
uint32_t b : 16;
uint32_t a : 16;
#else
#error or
specializations for BOOST_ENDIAN_LITTLE_WORD_BYTE_AVAILABLE/BOOST_ENDIAN_BIG_WORD_BYTE_AVAILABLE
#endif
};
This is error-prone and usually overlooked.
Therefore it would make sense to provide unique macros that guarantee that ONLY the contrary endianess is used in the else-branch, eg endian.hpp.txt. Now we can use correctly:
struct foo
{
#if defined(BOOST_ENDIAN_LITTLE_BYTE_UNIQUE_AVAILABLE)
uint32_t a : 16;
uint32_t b : 16;
#else
uint32_t b : 16;
uint32_t a : 16;
#endif
};
But this means that these unique-macros are actually used. It would probably make more sense to "teach" this behavior to the existing macros.
thx & regards
Gero