From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3188 invoked by alias); 9 Mar 2012 19:40:30 -0000 Received: (qmail 3178 invoked by uid 22791); 9 Mar 2012 19:40:29 -0000 X-SWARE-Spam-Status: No, hits=-6.7 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; Fri, 09 Mar 2012 19:40:14 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q29JdqWp015899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Mar 2012 14:39:52 -0500 Received: from host2.jankratochvil.net (ovpn-116-19.ams2.redhat.com [10.36.116.19]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q29Jdm3h017325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 9 Mar 2012 14:39:50 -0500 Date: Fri, 09 Mar 2012 19:40:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: Joel Brobecker , gdb-patches@sourceware.org Subject: cu_offset vs. sect_offset field names bikeshedding [Re: [patch 2/2] typedef-checking for CU relative vs. absolute offsets] Message-ID: <20120309193947.GA6256@host2.jankratochvil.net> References: <20120305223429.GM2867@adacore.com> <20120307170940.GA22619@host2.jankratochvil.net> <20120307171249.GB22619@host2.jankratochvil.net> <87eht2n4jf.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eht2n4jf.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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/msg00346.txt.bz2 Hi, On Thu, 08 Mar 2012 22:53:08 +0100, Tom Tromey wrote: > I think this patch is a good idea. I find that it does not clutter up > the code very much (which was my main concern), and it adds type-safety > to an area where we've clearly already had review and/or reasoning > failures. that's great, thanks for the agreement. Now just how to call them: > >>>>> "Jan" == Jan Kratochvil writes: > Jan> typedef struct { unsigned int co; } cu_offset; > Jan> typedef struct { unsigned int so; } sect_offset; I find 'cu_offset' + 'sect_offset' names for the types are OK, any objective? I do not find 'co' + 'so' great myself. 'val' + 'val' I do not find acceptable, it needs to differ, otherwise the expressions are a mess, the type of variable is not immediately visible. 'rel_off' + 'abs_off'? It no longer matches 'cu_offset' + 'sect_offset'. Moreover rel + abs I do not find so great, cu + sect I find better. 'rel_off' would be 7 characters, 23 lines of 143 lines of the patch would need reindentation overflowing 80 characters. field length | overflown lines of patch 3 3 4 7 5 13 6 15 7 23 8 27 9 31 10 35 11 41 12 45 13 47 14 47 15 49 Another proposal is 'cu_o' and 'sect_o' or even 'cu_off' or 'sect_off'. Regards, Jan