From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30012 invoked by alias); 5 May 2010 09:03:35 -0000 Received: (qmail 29577 invoked by uid 22791); 5 May 2010 09:03:32 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.157) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 May 2010 09:03:22 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o4593Fwk095516 ; Wed, 5 May 2010 11:03:16 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402:d::11]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id o4593F09093539 ; Wed, 5 May 2010 11:03:15 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o4593Fpg001108 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 5 May 2010 11:03:15 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Pedro Alves'" , References: <005b01caebe1$2183b890$648b29b0$@muller@ics-cnrs.unistra.fr> <201005050044.28991.pedro@codesourcery.com> In-Reply-To: <201005050044.28991.pedro@codesourcery.com> Subject: RE: [ARI] Remove all editCase warnings Date: Wed, 05 May 2010 09:03:00 -0000 Message-ID: <000901caec31$d109e640$731db2c0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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-05/txt/msg00090.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoy=E9=A0: Wednesday, May 05, 2010 1:44 AM > =C0=A0: gdb-patches@sourceware.org > Cc=A0: Pierre Muller > Objet=A0: Re: [ARI] Remove all editCase warnings >=20 > On Wednesday 05 May 2010 00:25:48, Pierre Muller wrote: > > ARI: Fix editCase. > > * ada-lang.c (ada_remove_Xbn_suffix): Rename to... > > (ada_remove_xbn_suffix): ...this. >=20 > The function really removes "X", not "x". You are right. =20 > > * addrmap.c (splay_compare_CORE_ADDR_ptr): Rename to... > > (splay_compare_core_addr_ptr): ...this. >=20 > errr. Don't care. I also don't really care... =20 > > * hppa-tdep.c (hppa_extract_5R_store): Rename to... > > (hppa_extract_r_store): ...this. >=20 > I don't know this code at all, but I wouldn't be suprised > if the 5r vs 5R had meaning to someone knowing hppa. (there's You are also most probably right. > a "5r" variant of this function above the "5R" variant.) E.g.,: I view that, that is why I used 5_r to replace 5R and not simply 5r...=20 > int hppa_extract_5_load (unsigned int); > unsigned hppa_extract_5R_store (unsigned int); > unsigned hppa_extract_5r_store (unsigned int); =20=20 =20=20 =20 > > * ia64-tdep.c (slotN_contents): Rename to... > > (slotn_contents): ...this. > > (replace_slotN_contents): Rename to... > > (replace_slotn_contents): ...this. >=20 > No comments. But I bet whoever wrote this was well aware > of our coding conventions and still chose an uppercase N. That's=20 >=20 > > * remote.c (set_remote_protocol_Z_packet_cmd): Rename to... > > (set_remote_protocol_z_packet_cmd): ...this. > > (show_remote_protocol_Z_packet_cmd): Rename to... > > (show_remote_protocol_z_packet_cmd): ...this. > > (store_register_using_P): Rename to... > > (store_register_using_p): ...this. > > (store_register_using_G): Rename to... > > (store_register_using_g): ...this. > > (remote_store_registers): Adapt to name changes above. > > (watchpoint_to_Z_packet): Rename to... > > (watchpoint_to_z_packet): ...this. >=20 > I'd rather not. Z, z, P, G, g, are all distinct packets, uppercase > having the opposite effect of lowercase. Example, you really store > with G, not g, which is for fetches (note the `fetch_registers_using_g' > function). Here I completely agree, I forgot that there were lowercase g and z packets. =20 > > * sol-thread.c (ps_lgetLDT): Add ARI comment for editCase. > > Adapt to name change in procfs.c source. >=20 > I'd bet this spelling was the reason for the `procfs_find_LDT_entry' > spelling in procfs.c. ps_lgetLDT is the main caller > of `procfs_find_LDT_entry'.=20 > > * windows-nat.c (_initialize_check_for_gdb_ini): Add ARI > > comment to all windows API replacement functions. >=20 > Honestly, I think this rule is one of those that generates > work for not such a great reason. IMO, code review enough catches > all the bad cases before they get to the tree. =20 My idea was to get rid of all issues so that I could mark that rule as a regression, and that it would thus get a much greater impact if new code would use such mixed case function names. =20=20 This way, we could either decide that the mixed case is not necessary and lowercase the function name, or add an ARI comment to accept that exception. I would tend to agree that adding an ARI comment is probably justified on most of these 18 functions. The only ones I am not sure about are: - splay_compare_CORE_ADDR_ptr in addrmap.c there are numerous other functions refereeing to CORE_ADDR type without using uppercase: $ grep "^[a-z_0-9]*core_addr" * arch-utils.c:core_addr_lessthan (CORE_ADDR lhs, CORE_ADDR rhs) arch-utils.c:core_addr_greaterthan (CORE_ADDR lhs, CORE_ADDR rhs) arch-utils.c:core_addr_identity (struct gdbarch *gdbarch, CORE_ADDR addr) proc-service.c:ps_addr_to_core_addr (psaddr_t addr) proc-service.c:core_addr_to_ps_addr (CORE_ADDR addr) ui-out.c:ui_out_field_core_addr (struct ui_out *uiout, utils.c:core_addr_to_string (const CORE_ADDR addr) utils.c:core_addr_to_string_nz (const CORE_ADDR addr) utils.c:string_to_core_addr (const char *my_string) =20=20 So I would like to eliminate that one. - the other two are proc_get_LDT_entry and procfs_find_LDT_entry in procfs.c these two functions are only called by=20 ps_lgetLDT inside sol-thread.c, which is, according to the comment required by libthread_db solaris library.=20 But I do not know if this also justifies propagating the uppercase use to the called functions in procfs.c Please tell me how I should proceed. Pierre