From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23000 invoked by alias); 21 Aug 2003 04:33:20 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22989 invoked from network); 21 Aug 2003 04:33:19 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 21 Aug 2003 04:33:19 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.9/8.12.9) with ESMTP id h7L4XEca031228; Wed, 20 Aug 2003 23:33:14 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h7L4XEHK018123; Wed, 20 Aug 2003 23:33:14 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.9/8.12.9/Submit) id h7L4XEiG018122; Thu, 21 Aug 2003 00:33:14 -0400 Date: Thu, 21 Aug 2003 04:33:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200308210433.h7L4XEiG018122@duracef.shout.net> To: ac131313@redhat.com Subject: Re: [rfa] space reduction in gdbtypes.h Cc: ezannoni@redhat.com, gdb-patches@sources.redhat.com, jimb@redhat.com X-SW-Source: 2003-08/txt/msg00357.txt.bz2 Andrew C says: > #define BOUND_BY_REF_IN_REG 2 > #define BOUND_BY_VALUE_IN_REG 1 > #define BOUND_SIMPLE 0 > - int upper_bound_type; > - int lower_bound_type; > + int upper_bound_type : 4; > + int lower_bound_type : 4; > > Hmm, doesn't this part scream ENUM? I agree, it does, but I wanted to patch one thing at a time, so I left it as an int. This data field is not actually functional at the moment. There are a few places that test the bounds. But there is only one place that sets any bounds at all. parse.c sets upper_bound_type to BOUND_CANNOT_BE_DETERMINED in one place. That's the only assignment I found. I suspect we're going to need some functional code in this area to fix several FORTRAN array bounds PR's. > Without that the packing is unsafe: > adding an extra variant that overflows the field won't be detected; > compilers capable of checking enum assignments won't do anything useful. Well, the definitions are right next to the use, which would make it obvious. And I hope that a person who adds new variants would test their new code at least ONCE to see if the new variants worked! Would you like me to go ahead and make this an enum right now? Michael C