From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17807 invoked by alias); 28 Mar 2012 04:19:57 -0000 Received: (qmail 17779 invoked by uid 22791); 28 Mar 2012 04:19:55 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Mar 2012 04:19:37 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2S4JabR017615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 28 Mar 2012 00:19:36 -0400 Received: from spoyarek (vpn-224-55.phx2.redhat.com [10.3.224.55]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2S4JX94019087; Wed, 28 Mar 2012 00:19:34 -0400 Date: Wed, 28 Mar 2012 04:19:00 -0000 From: Siddhesh Poyarekar To: Jan Kratochvil Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH] Allow 64-bit enum values Message-ID: <20120328095037.254b22ed@spoyarek> In-Reply-To: <20120327165950.GA1734@host2.jankratochvil.net> References: <20120220132724.GB4753@spoyarek.pnq.redhat.com> <87d397syts.fsf@fleche.redhat.com> <20120229135148.GA32128@spoyarek.pnq.redhat.com> <20120301224428.GA30631@host2.jankratochvil.net> <20120305063542.GA30196@spoyarek.pnq.redhat.com> <20120305080512.GA12311@host2.jankratochvil.net> <20120321100630.GA14496@spoyarek.pnq.redhat.com> <20120327165950.GA1734@host2.jankratochvil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00932.txt.bz2 On Tue, 27 Mar 2012 18:59:50 +0200 Jan Kratochvil wrote: > Sorry for respoding so late but what is the point of this enum and > offsets separation? Both need to become 64bit anyway so why to > separate them? > > Or you find it a better coding style this way? Better coding style is one of the reasons, to make the meaning of the elements unambiguous. The main reason for this separation is to match the types of bitpos and type.length exactly to retain the possibility of a typedef'd struct for their type. Something like: typedef struct { ULONGEST val; } struct_off_t; #define STRUCT_OFF_VAL(s) ((s).val) #define TYPE_LENGTH_VAL(t) STRUCT_OFF_VAL(TYPE_LENGTH(t)) #define TYPE_FIELD_BITPOS_VAL(t) STRUCT_OFF_VAL(TYPE_FIELD_BITPOS(t)) and do arithmetic like this: --- struct_off_t offset; return TYPE_LENGTH_VAL(t) + STRUCT_OFF_VAL(offset) - TYPE_FIELD_BITPOS_VAL(t) --- I hope this is OK. Regards, Siddhesh