From: bugzilla-daemon@bugzilla.kernel.org
To: linux-sparse@vger.kernel.org
Subject: [Bug 207959] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.
Date: Thu, 28 May 2020 21:24:35 +0000 [thread overview]
Message-ID: <bug-207959-200559-nznJfyeqKD@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-207959-200559@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=207959
--- Comment #3 from Luc Van Oostenryck (luc.vanoostenryck@gmail.com) ---
(In reply to Asher Gordon from comment #2)
> Perhaps '-Wno-universal-initializer' should be the default?
Well, that's really the point.
The problem Sparse also gives the warnings corresponding to clang's -Wnonnull
and my understanding is that these warnings are desired for the kernel even
when coming from using '{ 0 }'.
> > My very personal point of view is that the correct syntax should be '{ }'
> > because it conveys much better the idea of a default initializer. This
> > single zero in '{ 0 }' is just confusing.
>
> I can see your point, but unfortunately, as Ramsay Jones says here[1] and
> Alexander Monakov here[2], this is not standard C. So '{ }' isn't an option
> if we want to be portable.
Yes, I know, it's a pity. It's why I said 'should be'.
> Andrew Pinski's suggestion[3] is also an option,
> but that seems ugly to me.
Yes, it's far from ideal.
> I'm writing a library, Mu[4], which has a structure for which the
> 'designated_init' attribute is appropriate (see the 'MU_OPT' structure
> here[5]). However, I don't want to force my users not to use '{ 0 }', which
> is why I think this feature would be useful.
Interesting.
Yes, I understand. Git was in the same kind of situation, it's why I added
'-Wno-universal-initializer'. Can't you just add this option in your
SPARSE_FLAGS or something like that?
> Also, a minor note: In the test program I attached, the attribute needs to
> be specified after the closing brace to work with Sparse.
Yes, it's a known problem. Sparse accept 'type attributes' (those situated just
after the keyword 'struct', 'union' or 'enum') but ignore them.
I've some unfinished patches for this ... since some time already :(
--
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2020-05-28 21:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 16:27 [Bug 207959] New: Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute bugzilla-daemon
2020-05-28 19:22 ` [Bug 207959] " bugzilla-daemon
2020-05-28 19:57 ` [Bug 207959] New: " Ramsay Jones
2020-05-28 20:52 ` [Bug 207959] " bugzilla-daemon
2020-05-28 21:24 ` bugzilla-daemon [this message]
2020-05-28 22:25 ` Linus Torvalds
2020-05-28 22:26 ` bugzilla-daemon
2020-05-28 22:31 ` bugzilla-daemon
2020-05-28 22:47 ` bugzilla-daemon
2020-05-29 19:35 ` bugzilla-daemon
2020-05-29 19:47 ` bugzilla-daemon
2020-06-08 7:53 ` bugzilla-daemon
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=bug-207959-200559-nznJfyeqKD@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-sparse@vger.kernel.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 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).