On Tue, Jun 04, 2019 at 09:48:12PM +0900, Masahiro Yamada wrote: > On Tue, Jun 4, 2019 at 8:55 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > On Tue, Jun 4, 2019 at 1:23 PM Joe Perches <joe@xxxxxxxxxxx> wrote: > > > > > > On Tue, 2019-06-04 at 20:13 +0900, Masahiro Yamada wrote: > > > > On the other hand, uapi headers are written in more strict C, where > > > > the C++ comment style is forbidden. > > > > > > Is this a real problem for any toolchain? > > > > There is likely some code that is built with -Wpedandic -Werror --std=c89 > > or similar. Since glibc allows this combination for its own headers, it seems > > best to also allow it in kernel headers that may be included by libc headers > > or by applications, at least where it does not hurt. > > > > Realistically though, we probably assume c99 or gnu89 in user space > > headers anyway, since there is no 'long long' in earlier standards. > > > > Arnd > > In fact, I detected this issue by the following patch: > https://patchwork.kernel.org/patch/10974669/ > > When I worked on it, I wondered which > c-dialect flags should be used. > > This code: > > > # Unlike the kernel space, uapi headers are written in more strict C. > > # - Forbid C++ style comments > > # - Use '__inline', '__asm__' instead of 'inline', 'asm' > > # > > # -std=c90 (equivalent to -ansi) catches the violation of those. > > # We cannot go as far as adding -Wpedantic since it emits too many warnings. > > # > > # REVISIT: re-consider the proper set of compiler flags for uapi compile-test. > > > > UAPI_CFLAGS := -std=c90 -Wpedantic -Wall -Werror=implicit-function-declaration > > Even "-std=c99 -Wpedantic" emits lots of warnings. > > > > I noticed one more thing. > > There are two ways to define fixed-width type. > > [1] #include <linux/types.h>, __u8, __u16, __u32, __u64 > > vs > > [2] #include <stdint.h>, uint8_t, uint16_t, uint32_t, uint64_t > > > Both are used in UAPI headers. > IIRC, <stdint.h> was standardized by C99. > > So, we have already relied on C99 in user-space too. Just because we have relied on it in the past, does not mean we need to keep relying on it. I have had numerous complaints over the years from libc authors that our uapi headers are _NOT_ able to be directly consumed by them. They all end up having to fix things up and include local "sanitized" copies. So any work we can do here to make them more sane and work properly everywhere is a good thing, as right now, they are broken. thanks, greg k-h
