On 21 May 2013 11:43, Richard Earnshaw <rearn...@arm.com> wrote: > Why don't you add a (maybe cut-down) stdint.h to the kernel. It seems > bizarre to me that the kernel is trying to provide standard types through a > non-standard interface. >
There have been heated debates going on for years about these things. Quote from Linus Torvalds: (http://yarchive.net/comp/linux/kernel_headers.html) " The user is supposed to see "int32_t" and friends _only_ if the user himself includes <stdint.h> or one of the very specific headers that is documented by the standard to include it. Trust me. We are NOT going to use <stdint.h> in the kernel. " This is fairly old, and some of the types have in fact been added to <linux/types.h>, even if stdint.h is still absent. The bottom line is that including arm_neon.h pulls in a host of stuff into the namespace, even with -ffreestanding. (And in that case, the fact that GCC built for bare metal and GCC built for GLIBC disagree on the definition of __UINTPTR_TYPE__ is not helping a lot either) I understand that the uintXX_t types have already been made part of the public NEON instrinsics interface, so I am not proposing changing that. I am just looking for a way to enable the use of NEON intrinsics in the kernel. Are there any other solution possible in your opinion? Do you agree that POSIX states that stdint.h may only be included in specific well defined cases? Could we perhaps make the #inclusion conditional? An alternate header perhaps to accomodate non-C99 environments? Regards, Ard.
