On 18/07/13 17:22, Ard Biesheuvel wrote: > On 18 July 2013 16:54, Tejas Belagod <tbela...@arm.com> wrote: >> I'd like to follow up this thread to move towards removing arm_neon.h's >> dependence on stdint.h. My comments inline below. >> >>> As far as I can tell, the only dependency arm_neon.h has on the >>> contents of that header are the [u]int[8|16|32|64]_t typedefs. The >>> kernel does define those, only in a different header. >>> >> > > Hello Tejas, > > What I did not realize at the time is that those types are part of the > visible interface of the NEON intrinsics. Just as an example, there is > a function in arm_neon.h: > > uint8x8_t vset_lane_u8 (uint8_t __a, uint8x8_t __b, const int __c); > > which clearly needs a type definition for uint8_t. Changing the > published and documented interface is unlikely to be a realistic > option, I'm afraid, and simply dropping the #include will cause > breakage for some existing users, which is also not very appealing. > > Conditionally including stdint.h in case those types have not been > defined (yet) would be the only remaining option, I think, but I am > not sure if that is feasible. > > In the kernel case, I have worked around it by having a separate > compilation unit containing the wrapped NEON intrinsics code, and > using plain old C types to interface with the wrapper functions. > > [...] > > Regards, > Ard. >
Since you need definitions of uint8_t and friends, and they can come from either linux/types.h or stdint.h, why not check both? #ifdef _LINUX_TYPES_H // We have the types from <linux/types.h> #else #ifdef _STDINT_H // We have them from <stdint.h> #else #include <stdint.h> // or #include <linux/types.h> #endif #endif (I don't know which header is preferred for the default include).