From: Greg KH <gregkh@linuxfoundation.org>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Joe Perches <joe@perches.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Randy Dunlap <rdunlap@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] media: do not use C++ style comments in uapi headers
Date: Tue, 4 Jun 2019 15:42:13 +0200 [thread overview]
Message-ID: <20190604134213.GA26263@kroah.com> (raw)
In-Reply-To: <CAK7LNAS0Ph2Z6x0-UPSkJUC31NvPi09BmFrve+YJcXMrop-BGA@mail.gmail.com>
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@arndb.de> wrote:
> >
> > On Tue, Jun 4, 2019 at 1:23 PM Joe Perches <joe@perches.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
next prev parent reply other threads:[~2019-06-04 13:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-04 11:13 [PATCH] media: do not use C++ style comments in uapi headers Masahiro Yamada
2019-06-04 11:23 ` Joe Perches
2019-06-04 11:48 ` Masahiro Yamada
2019-06-04 12:04 ` Joe Perches
2019-06-04 11:54 ` Arnd Bergmann
2019-06-04 12:48 ` Masahiro Yamada
2019-06-04 13:32 ` Masahiro Yamada
2019-06-04 13:42 ` Greg KH [this message]
2019-06-04 15:27 ` Masahiro Yamada
2019-06-04 18:20 ` Arnd Bergmann
2019-06-05 4:10 ` Masahiro Yamada
2019-06-05 5:10 ` Greg KH
2019-06-05 5:22 ` Joe Perches
2019-06-05 6:02 ` Greg KH
2019-06-05 10:08 ` Masahiro Yamada
2019-06-05 10:14 ` Mauro Carvalho Chehab
2019-06-05 17:03 ` Joe Perches
2019-06-09 7:14 ` Masahiro Yamada
2019-06-09 11:55 ` Joe Perches
2019-06-09 13:08 ` Masahiro Yamada
2019-06-09 13:35 ` Joe Perches
2019-06-09 17:19 ` Masahiro Yamada
2019-06-09 17:42 ` Pavel Machek
2019-06-16 15:48 ` Pavel Machek
2019-06-04 14:42 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190604134213.GA26263@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=rdunlap@infradead.org \
--cc=tglx@linutronix.de \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).