From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Aleksa Sarai <asarai-l3A5Bk7waGM@public.gmane.org>
Cc: Nick Desaulniers
<nick.desaulniers-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Michael Davidson <md-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Greg Hackmann <ghackmann-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
android-llvm-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH] cgroup: reorder flexible array members of struct cgroup_root
Date: Sat, 21 Oct 2017 09:03:08 -0700 [thread overview]
Message-ID: <20171021160308.GN1302522@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <85d7f6eb-7869-551d-01b1-fa1712f4bd40-l3A5Bk7waGM@public.gmane.org>
On Sun, Oct 22, 2017 at 02:59:33AM +1100, Aleksa Sarai wrote:
> >Here, not necessarily but I don't want to move it for a bogus reason.
> >Why would we disallow embedding structs with flexible members in the
> >middle when it can be done and is useful? If we want to discuss
> >whether we want to avoid such usages in the kernel (but why?), sure,
> >let's have that discussion but we can't decide that on "clang warns on
> >it by default".
>
> There was a talk a few years ago by the clang folks[1] saying that
> while trying to build a kernel with clang, they discovered that
> several places in the kernel uses "VLAIS" (variable Length Arrays In
> Structs") and argued that this is a violation of the C
> specification, despite it being a GNU extension. They also submitted
> several patches that removed this code (even working around a
> user-space visible usage of VLAIS).
The kernel is explicitly using GNU extended version of C and has
always from the beginning, so not-std-c isn't a valid argument.
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Aleksa Sarai <asarai@suse.de>
Cc: Nick Desaulniers <nick.desaulniers@gmail.com>,
Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
cgroups@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Matthias Kaehlcke <mka@chromium.org>,
Michael Davidson <md@google.com>,
Greg Hackmann <ghackmann@google.com>,
android-llvm@google.com
Subject: Re: [PATCH] cgroup: reorder flexible array members of struct cgroup_root
Date: Sat, 21 Oct 2017 09:03:08 -0700 [thread overview]
Message-ID: <20171021160308.GN1302522@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <85d7f6eb-7869-551d-01b1-fa1712f4bd40@suse.de>
On Sun, Oct 22, 2017 at 02:59:33AM +1100, Aleksa Sarai wrote:
> >Here, not necessarily but I don't want to move it for a bogus reason.
> >Why would we disallow embedding structs with flexible members in the
> >middle when it can be done and is useful? If we want to discuss
> >whether we want to avoid such usages in the kernel (but why?), sure,
> >let's have that discussion but we can't decide that on "clang warns on
> >it by default".
>
> There was a talk a few years ago by the clang folks[1] saying that
> while trying to build a kernel with clang, they discovered that
> several places in the kernel uses "VLAIS" (variable Length Arrays In
> Structs") and argued that this is a violation of the C
> specification, despite it being a GNU extension. They also submitted
> several patches that removed this code (even working around a
> user-space visible usage of VLAIS).
The kernel is explicitly using GNU extended version of C and has
always from the beginning, so not-std-c isn't a valid argument.
Thanks.
--
tejun
next prev parent reply other threads:[~2017-10-21 16:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-17 6:33 [PATCH] cgroup: reorder flexible array members of struct cgroup_root Nick Desaulniers
2017-10-17 6:33 ` Nick Desaulniers
2017-10-17 6:40 ` Nick Desaulniers
[not found] ` <20171017064051.tudsi33f4spuyi25-i8pvpzbnxTwmroCTmvX//g@public.gmane.org>
2017-10-17 6:45 ` Nick Desaulniers
2017-10-17 6:45 ` Nick Desaulniers
2017-10-18 13:30 ` Tejun Heo
2017-10-20 7:15 ` Nick Desaulniers
[not found] ` <CAH7mPvjksNSDo4o=z51YkH4yX+gDnGXU-g59gTkOUS-pEva8sA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-10-21 15:32 ` Tejun Heo
2017-10-21 15:32 ` Tejun Heo
[not found] ` <20171021153253.GG1302522-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2017-10-21 15:59 ` Aleksa Sarai
2017-10-21 15:59 ` Aleksa Sarai
[not found] ` <85d7f6eb-7869-551d-01b1-fa1712f4bd40-l3A5Bk7waGM@public.gmane.org>
2017-10-21 16:03 ` Tejun Heo [this message]
2017-10-21 16:03 ` Tejun Heo
2017-10-21 19:08 ` Nick Desaulniers
2017-10-25 21:54 ` Matthias Kaehlcke
2017-10-25 21:54 ` Matthias Kaehlcke
[not found] ` <20171025215423.GD96615-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2017-10-26 14:32 ` Tejun Heo
2017-10-26 14:32 ` Tejun Heo
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=20171021160308.GN1302522@devbig577.frc2.facebook.com \
--to=tj-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=android-llvm-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=asarai-l3A5Bk7waGM@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=ghackmann-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=md-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=nick.desaulniers-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.