From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5713 invoked by alias); 1 Oct 2013 14:16:32 -0000 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 Received: (qmail 5698 invoked by uid 89); 1 Oct 2013 14:16:31 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 01 Oct 2013 14:16:31 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r91EGOm0009900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Oct 2013 10:16:25 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r91EGMLC005023; Tue, 1 Oct 2013 10:16:23 -0400 Message-ID: <524AD936.7060604@redhat.com> Date: Tue, 01 Oct 2013 14:16:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Agovic, Sanimir" CC: "'Mark Kettenis'" , "ooprala@redhat.com" , "gdb-patches@sourceware.org" Subject: Re: C++-compat clean build References: <524AB12E.8090209@redhat.com> <201310011204.r91C4QVo006124@glazunov.sibelius.xs4all.nl> <0377C58828D86C4588AEEC42FC3B85A7176850E2@IRSMSX105.ger.corp.intel.com> In-Reply-To: <0377C58828D86C4588AEEC42FC3B85A7176850E2@IRSMSX105.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00053.txt.bz2 On 10/01/2013 01:53 PM, Agovic, Sanimir wrote: > Thanks Ondrej for taking the initiative! > > >> -----Original Message----- >> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf >> Of Mark Kettenis >> Sent: Tuesday, October 01, 2013 02:04 PM >> To: ooprala@redhat.com >> Cc: gdb-patches@sourceware.org >> Subject: Re: C++-compat clean build >> >> Rejected. Introducing all these casts can't be right. They hide type >> conversion issues and make the code unreadable. >> > Afaik, some casts are required to some extend as C++ does no implicit from/to void * > conversion. But in general I agree about using casts too vast. > > @@ -1598,7 +1598,7 @@ amd64_relocate_instruction (struct gdbarch *gdbarch, > int len = gdbarch_max_insn_length (gdbarch); > /* Extra space for sentinels. */ > int fixup_sentinel_space = len; > - gdb_byte *buf = xmalloc (len + fixup_sentinel_space); > + gdb_byte *buf = (gdb_byte *) xmalloc (len + fixup_sentinel_space); > This looks OK to me and could be replaced with a type save new[] once C++ is used. libiberty gives us a series of macros that kind of mirror c++ new/new[] (minus the constructors, of course): libiberty.h:#define XALLOCA(T) ((T *) alloca (sizeof (T))) ... libiberty.h:#define XNEW(T) ((T *) xmalloc (sizeof (T))) libiberty.h:#define XCNEW(T) ((T *) xcalloc (1, sizeof (T))) libiberty.h:#define XNEWVEC(T, N) ((T *) xmalloc (sizeof (T) * (N))) libiberty.h:#define XCNEWVEC(T, N) ((T *) xcalloc ((N), sizeof (T))) libiberty.h:#define XNEWVAR(T, S) ((T *) xmalloc ((S))) libiberty.h:#define XCNEWVAR(T, S) ((T *) xcalloc (1, (S))) ... etc. so this case could be written as: gdb_byte *buf = XNEWVAR (gdb_byte, len + fixup_sentinel_space); This: struct foo *f = (struct foo *) xmalloc (sizeof (struct foo)); Can be written as: struct foo *f = XNEW (struct foo); There are variants for alloca as well. We have several uses of these macros already in the tree. They seem to have the advantage that they hide the casts and perhaps make the intention of the code clearer while we can't use new/new[]. E.g., XNEW prevents errors of the type: struct foo *f = (struct foo *) xmalloc (sizeof (f)); We already use these macros in gdb in several places. Not sure what people feel about using them more? -- Pedro Alves