mi.h: Use ccan/endian/endian.h instead of endian.h#835
Conversation
tbzatek
left a comment
tbzatek
left a comment
There was a problem hiding this comment.
Unfortunately <mi.h> is part of public API as included from <libnvme-mi.h> while ccan is a private in-tree library.
|
OK. Then I'll update ccan/endian/endian.h to only define these if they aren't already defined. glibc already defines them, but there's no warning because it's the same thing. FreeBSD has migrated to using the clang/gcc builtin values, and so gets a redefinition warning. Thanks for the feedback. |
When both endian.h and ccan/endian/endian.h are included, we can have
__{BIG,LITTLE}_ENDIAN redefined when compiling with clang on FreeBSD.
Clang and gcc have moved to a predefine for endian orders. glibc defines
these the same as they are defied here, but that's an unsafe assumption
to make. Instead, only define them when __LITTLE_ENDIAN not defined as a
fallback to when the host does not define them in the standard system
headers.
Signed-off-by: Warner Losh <imp@bsdimp.com>
|
The fix looks good as far I understand. Though we should try to get this upstream to the ccan project eventually. |
Do you have a pointer to ccan? Google is returning results about 'can' and not so much where to find the upstream. If it's an open project, I'd be happy to do the legwork to push it upstream there. |
|
@bsdimp - I think this is the ccan repo location: |
|
Thanks! For your tracking purposes: |
4 participants
[[ edited ]]
When both endian.h and ccan/endian/endian.h are included, we can have
__{BIG,LITTLE}_ENDIAN redefined when compiling with clang on FreeBSD.
Clang and gcc have moved to a predefine for endian orders. glibc defines
these the same as they are defied here, but that's an unsafe assumption
to make. Instead, only define them when __LITTLE_ENDIAN not defined as a
fallback to when the host does not define them in the standard system
headers.