From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23516 invoked by alias); 10 Dec 2010 00:34:57 -0000 Received: (qmail 23299 invoked by uid 22791); 10 Dec 2010 00:34: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; Fri, 10 Dec 2010 00:34:50 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBA0Yn7f009725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Dec 2010 19:34:49 -0500 Received: from mesquite.lan ([10.3.113.8]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oBA0YmkY014309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 9 Dec 2010 19:34:49 -0500 Date: Fri, 10 Dec 2010 00:34:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [RFC] mips-tdep.c: Update mips_register_to_value(), et al... Message-ID: <20101209173448.47fe4f14@mesquite.lan> In-Reply-To: <4D009AE4.9070606@codesourcery.com> References: <20101208164657.7d9ce88e@mesquite.lan> <4D009AE4.9070606@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: 2010-12/txt/msg00126.txt.bz2 On Thu, 09 Dec 2010 17:01:24 +0800 Yao Qi wrote: > On 12/09/2010 07:46 AM, Kevin Buettner wrote: > > (Can anyone think of better names for the two new functions that I > > introduced?) > > > > * mips-tdep.c (big_endian_4_byte_fp_reg_with_double_type_p) > > (eight_byte_gp_reg_with_shorter_type_p): New functions. > > Names of these two new functions are a little bit long. :-) I agree that they are long, but are they too long? Here, taken from the patch, are the various uses of these functions: mips_convert_register_p: + return big_endian_4_byte_fp_reg_with_double_type_p (gdbarch, regnum, type) + || eight_byte_gp_reg_with_shorter_type_p (gdbarch, regnum, type); mips_register_to_value and mips_value_to_register: + if (big_endian_4_byte_fp_reg_with_double_type_p (gdbarch, regnum, type)) + else if (eight_byte_gp_reg_with_shorter_type_p (gdbarch, regnum, type)) Note that the names are just (barely) short enough that the function parameters do not need to be placed on a separate line. > Sometimes, it is hard to describe function's behavior only by its name. > Can we name them as mips_convert_register_p_{1,2}, and give comments in > details to each of them? That could be done. I would prefer to use names that are a bit more descriptive though. I think that the names that I have chosen, as bad as they are, still make the code easier to understand than if generic predicate names were used. I was hoping that someone would suggest some names that are shorter, but still reasonably descriptive. But, as you say, that might not be possible. Hmm... Maybe it'd work out better if I put less detail in the name. How about these names? mips_convert_register_float_case_p mips_convert_register_gpreg_case_p (Or something along those lines...) You'd still have to read the code, or possibly a comment, to find out the precise meaning of the predicate, but the names contain just enough information so that one won't unwittingly be confused with the other. Kevin