From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Nicolai Stange <nicstange@gmail.com>
Cc: linux-sparse@vger.kernel.org
Subject: Re: [PATCH RFC 07/13] evaluate: check static storage duration objects' intializers' constness
Date: Mon, 11 Jan 2016 19:02:05 +0100 [thread overview]
Message-ID: <20160111180205.GD2972@macpro.local> (raw)
In-Reply-To: <8737u6wfpj.fsf@gmail.com>
On Sat, Jan 09, 2016 at 11:28:08PM +0100, Nicolai Stange wrote:
> Luc Van Oostenryck <luc.vanoostenryck@gmail.com> writes:
>
> > On Thu, Jul 23, 2015 at 01:19:09AM +0200, Nicolai Stange wrote:
> >> Initializers of static storage duration objects shall be constant
> >> expressions [6.7.8(4)].
> >>
> >> Warn if that requirement is not met.
> >>
> >> Identify static storage duration objects by having either of
> >> MOD_TOPLEVEL or MOD_STATIC set.
> >>
> >> Check an initializer's constness at the lowest possible subobject
> >> level, i.e. at the level of the "assignment-expression" production
> >> in [6.7.8].
> >>
> >> For compound objects, make handle_list_initializer() pass the
> >> surrounding object's storage duration modifiers down to
> >> handle_simple_initializer() at subobject initializer evaluation.
> >
> >
> > This patch makes validation/{builtin_bswap,choose_expr}.c fail.
> > Of course, it's directly related to the purpose of the patch but
> > then the test should be adapted.
> >
>
> Yes, you are absolutely right. However, as mentioned in this RFC series'
> cover letter, I decided to leave these two failers as is "for the moment".
It's fine then.
I just wanted to be sure that you was aware of it.
> Certainly this is anything but best practice and I can only
> apologize for sending you half (well 97%) baken patches -- and promise
> to never do it again...
Personally, I think that drafts are very fine.
They're the basis on which we, developers, can exchange ideas.
And your patches are far from drafts, they are already finely coocked.
But just to be sure to avoid any misunderstanding:
you know that I'm not the maintainer, just a reviewer. Right?
Yours,
Luc
next prev parent reply other threads:[~2016-01-11 18:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 23:19 [PATCH RFC 07/13] evaluate: check static storage duration objects' intializers' constness Nicolai Stange
2016-01-09 18:04 ` Luc Van Oostenryck
2016-01-09 22:28 ` Nicolai Stange
2016-01-11 18:02 ` Luc Van Oostenryck [this message]
2016-01-11 18:15 ` Nicolai Stange
2016-01-11 19:28 ` Josh Triplett
2016-12-08 4:48 ` [PATCH] Update maintainers in the manpage Luc Van Oostenryck
2016-12-08 5:43 ` Josh Triplett
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=20160111180205.GD2972@macpro.local \
--to=luc.vanoostenryck@gmail.com \
--cc=linux-sparse@vger.kernel.org \
--cc=nicstange@gmail.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).