linux-kernel - Re: [PATCH] media: do not use C++ style comments in uapi headers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190604134213.GA26263@kroah.com>
Date:   Tue, 4 Jun 2019 15:42:13 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Arnd Bergmann <arnd@...db.de>, Joe Perches <joe@...ches.com>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Randy Dunlap <rdunlap@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] media: do not use C++ style comments in uapi headers

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@...db.de> wrote:
> >
> > On Tue, Jun 4, 2019 at 1:23 PM Joe Perches <joe@...ches.com> 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