linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Kamil Dudka <kdudka@redhat.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>, linux-sparse@vger.kernel.org
Subject: Re: sparse segv with simple test
Date: Mon, 31 Aug 2009 13:53:54 -0700	[thread overview]
Message-ID: <20090831205353.GA6239@josh-work.beaverton.ibm.com> (raw)
In-Reply-To: <200908312104.54990.kdudka@redhat.com>

On Mon, Aug 31, 2009 at 09:04:54PM +0200, Kamil Dudka wrote:
> On Monday 31 of August 2009 20:49:00 Stephen Hemminger wrote:
> > > But it might be good idea to implement such out-of-range detection ;-)
> >
> > Yes, I was looking to use more enum's in places where int was used in the
> > kernel. There were places where the interface expected a limit range of
> > values like network device transmit, but the interface was being misused
> > and caller was returning errno values.
> 
> Generally you can't simply check if the value is in a *range* since the enum 
> values could be non-continuous. You need to check for all continuous 
> sub-ranges or even for all values.
> 
> What about issuing a warning for any assignment of int value to enum? (as it 
> is already checked by a C++ compiler) Such places are IMHO always suspicious. 
> If you know what you are doing you can still cast it explicitly to avoid such 
> warning.

That seems quite sensible, and it even seems like something sparse
should warn about by default.

The reverse, warning about the assignment of an enum value to int, seems
useful as well, but sparse shouldn't issue that warning by default
because a lot of code just uses enum to define constants.

Distinguishing between anonymous and named enums seems useful as well.
An anonymous enum just creates some named constants but doesn't create a
type to use them with, so assigning those constants to int shouldn't
generate a warning.  (Corner case: "enum { ... } foo;".)

- Josh Triplett

  reply	other threads:[~2009-08-31 20:53 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 [this message]
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
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=20090831205353.GA6239@josh-work.beaverton.ibm.com \
    --to=josh@joshtriplett.org \
    --cc=kdudka@redhat.com \
    --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).