From: Kamil Dudka <kdudka@redhat.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Josh Triplett <josh@joshtriplett.org>,
Stephen Hemminger <shemminger@vyatta.com>,
linux-sparse@vger.kernel.org
Subject: Re: [PATCH] add warnings enum-to-int and int-to-enum
Date: Wed, 2 Sep 2009 21:58:14 +0200 [thread overview]
Message-ID: <200909022158.14425.kdudka@redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.0909021458180.28290@iabervon.org>
On Wednesday 02 of September 2009 21:19:46 Daniel Barkalow wrote:
> On Wed, 2 Sep 2009, Josh Triplett wrote:
> > On Wed, Sep 02, 2009 at 02:43:52PM -0400, Daniel Barkalow wrote:
> > > On Wed, 2 Sep 2009, Kamil Dudka wrote:
> > > > On Wednesday 02 of September 2009 19:56:47 Daniel Barkalow wrote:
> > > > > It feels to me like the explicit numeric values are what make these
> > > > > constants sensible to use directly as ints, and that it's only
> > > > > sensible to use a non-constant value of an enum type as an int
> > > > > (without an explicit cast) if all of the enum values have explicit
> > > > > numeric values.
> > > > >
> > > > > I think:
> > > > >
> > > > > enum {
> > > > > my_register_zero
> > > > > ...
> > > > > my_register_twdr
> > > > > my_register_twcr
> > > > > ...
> > > > > };
> > > > >
> > > > > void () {
> > > > > write_register(my_register_twdr, SETUP_TWDR);
> > > > > }
> > > > >
> > > > > is asking for trouble in a way that this warning is about.
> > > >
> > > > Both examples are too abstract for me -- missing declaration
> > > > of write_register(), etc. Please attach a minimal example as a file
> > > > which I can compile and test. I'll check if the "trouble" is covered
> > > > by the warnings or not, and perhaps implement what's missing. Thanks
> > > > in advance!
> > >
> > > enum {
> > > foo,
> > > bar
> > > };
> > >
> > > enum {
> > > baz = 1,
> > > qux = 2
> > > };
> > >
> > > void test(void) {
> > > int i = bar; // warn on this
> > > int j = qux; // okay
> > > }
> > >
> > > (Leaving aside the issue of whether the enum is anonymous)
> > >
> > > In the "bar" case, an additional value added somewhere in the list
> > > (particularly if the list were long) might change "i" in a way that
> > > wouldn't necessarily be obvious to users of "i". In the "qux" case, "j"
> > > would only change if the "qux = 2" line were changed.
> >
> > I disagree with this. In both cases, you've declared an anonymous enum,
> > and then used its values as constants. In the former case, you might
> > just not care about the values except to compare against each other;
> > granted, you ought to use a named enum rather than an int in that case,
> > but nevertheless much code exists that uses int instead of enum types.
>
> I think anonymous vs named enums are one thing that should affect whether
> you get a warning, and explicit values vs implicit values are another
> factor, but I don't have an opinion on which way they should combine.
> Probably either using an explicit value or an anonymous enum should be
> okay by default, and the test above should use named enums.
I think type-checking is the way to go, not values checking... Once you start
to count with "explicit" vs. "implicit" enum values, you will sooner or later
run in troubles like this:
enum { A, B = 3, C, D = A + 7 };
enum { Z = (C < D) ? A : B };
Kamil
next prev parent reply other threads:[~2009-09-02 19:59 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-30 22:32 sparse segv with simple test Stephen Hemminger
2009-08-30 22:53 ` Kamil Dudka
2009-08-31 15:57 ` Stephen Hemminger
2009-08-31 18:12 ` Kamil Dudka
2009-08-31 18:49 ` Stephen Hemminger
2009-08-31 19:04 ` Kamil Dudka
2009-08-31 20:53 ` Josh Triplett
2009-09-01 21:59 ` [PATCH] add warnings enum-to-int and int-to-enum Kamil Dudka
2009-09-01 23:24 ` Josh Triplett
2009-09-02 0:27 ` Stephen Hemminger
2009-09-02 17:56 ` Daniel Barkalow
2009-09-02 18:04 ` Kamil Dudka
2009-09-02 18:43 ` Daniel Barkalow
2009-09-02 18:56 ` Josh Triplett
2009-09-02 19:19 ` Daniel Barkalow
2009-09-02 19:58 ` Kamil Dudka [this message]
2009-09-02 11:53 ` Kamil Dudka
2009-09-02 15:21 ` Josh Triplett
2009-09-02 16:23 ` Kamil Dudka
2009-09-02 16:38 ` Christopher Li
2009-09-02 19:03 ` Josh Triplett
2009-09-02 19:19 ` Kamil Dudka
2009-09-02 22:35 ` Kamil Dudka
2009-09-03 9:42 ` Christopher Li
2009-09-03 11:47 ` Kamil Dudka
2009-09-03 18:38 ` Christopher Li
2009-09-03 18:54 ` Kamil Dudka
2009-09-03 20:02 ` Christopher Li
2009-09-13 19:28 ` Kamil Dudka
2009-09-13 19:55 ` Christopher Li
2009-09-13 20:09 ` Kamil Dudka
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=200909022158.14425.kdudka@redhat.com \
--to=kdudka@redhat.com \
--cc=barkalow@iabervon.org \
--cc=josh@joshtriplett.org \
--cc=linux-sparse@vger.kernel.org \
--cc=shemminger@vyatta.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).