From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5304 invoked by alias); 15 Oct 2002 03:28:31 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5295 invoked from network); 15 Oct 2002 03:28:30 -0000 Received: from unknown (HELO egil.codesourcery.com) (66.92.14.122) by sources.redhat.com with SMTP; 15 Oct 2002 03:28:30 -0000 Received: from zack by egil.codesourcery.com with local (Exim 3.36 #1 (Debian)) id 181INf-0003vg-00; Mon, 14 Oct 2002 20:28:27 -0700 Date: Mon, 14 Oct 2002 22:01:00 -0000 To: Jamie Lokier Cc: Kevin Lawton , gcc@gcc.gnu.org Subject: Re: Request of new __attribute__ for switch statements (elimination of the bounds check) Message-ID: <20021015032827.GA15067@codesourcery.com> References: <20021011190521.57024.qmail@web80309.mail.yahoo.com> <20021015014101.GB27718@bjl1.asuk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021015014101.GB27718@bjl1.asuk.net> User-Agent: Mutt/1.4i From: Zack Weinberg X-SW-Source: 2002-10/txt/msg00777.txt.bz2 On Tue, Oct 15, 2002 at 02:41:01AM +0100, Jamie Lokier wrote: > I would prefer to have an attribute on enumurated types that says a > value of that type is always one of the enum values: > > enum __attribute__ ((strict_enum)) { CAT, FISH, RABBIT } Pet; > > (It would be appropriate to add a warning when an enum with this > attribute is converted to an integer). > > Then any switch statement, without adornment, would be able to assume > a value of that type is in the range. _If_ every enum label is > mentioned in the switch, there is no need for the bounds check. (GCC > already checks enum labels in a switch if `-Wswitch' is used, which > may be helpful). If there is an enumerated type that doesn't exhaust the domain of its underlying integral type, then I confidently expect that a data corruption bug will cause the switch to receive a selector outside the domain of the enumeration; in that case I want there to be a default:abort() in there so it gets caught early. This does not mean that your idea is a bad one; the attribute could be used for stricter type checking and more effective warnings, which is a good thing. I just don't like the idea of using it to optimize out bounds checks. (Instead, how about transforming your example > Pet my_pet; > /* ... */ > switch (my_pet) { > case CAT: /* ... */ > case FISH: /* ... */ > case RABBIT: /* ... */ > } by inserting the default:abort() for the programmer?) > You can use this attribute to achieve Kevin's goal of faster threaded > interpretation, but it is a bit ugly. For a byte-code dispatch, you'd > have to define an enum with 256 scratch names, and cast your byte to > that type in the switch. For a sparse dispatch, you'd have to use a > different enum type. It's a bit ugly but might be ok with macros. I would far rather solve this problem by having us notice when a dispatch switch() really has exhausted the domain of the integral type of its argument (before conversion to int). zw