From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126813 invoked by alias); 27 Apr 2016 06:19:44 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 126801 invoked by uid 89); 27 Apr 2016 06:19:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=*out, subseg_get, saber, Hx-languages-length:3308 X-HELO: mail-pa0-f41.google.com Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com) (209.85.220.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 27 Apr 2016 06:19:33 +0000 Received: by mail-pa0-f41.google.com with SMTP id r5so15764026pag.1 for ; Tue, 26 Apr 2016 23:19:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=zH6Z90P/VbZKEDWgUFba53mhnwN6X+WL+mMkBcYF7Zo=; b=jeJj0dqzsVgSgYA1CIo1lF4YndzPCEq0fb2kZYWSxgfs5V/u/+GqtH6nYVs8xBHbjX pO6T51xMClIh7E0pNHG6xn85tjyeqg0XzMmNpLNNFdqoByMbHjZsh74ScXFrMIfgnLQv r41SXiP4L3StOT2I8oSD1Ee8T+6hihnKOBg2IdrWwVpbJqvcjswG4Vb8voz/41KtG3tg 4kn7/8wg8+bk9Spmv0jfFDvjOLuvztpU3gF9U/R26c4HhOaqjivFJZC0AQ7txz/X9juU 9YfXjrTcwQve3POJ4ebMiq6BPA9bMxAKEJbmHvmwm2IqrQIoU5QtIneJ29rOY8SOrPx7 c+pQ== X-Gm-Message-State: AOPr4FXt5EpxO6CF4Jqrr4uKzI7ZfgzR8ZNN6DEYekXqgFQjyhQ+hvdT4QDU1IKhmUb2YQ== X-Received: by 10.66.199.66 with SMTP id ji2mr9418731pac.34.1461737971570; Tue, 26 Apr 2016 23:19:31 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-160-146-233.sa.bigpond.net.au. [58.160.146.233]) by smtp.gmail.com with ESMTPSA id x89sm3044219pfa.87.2016.04.26.23.19.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Apr 2016 23:19:30 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 944C5EA0157; Wed, 27 Apr 2016 15:49:25 +0930 (ACST) Date: Wed, 27 Apr 2016 06:19:00 -0000 From: Alan Modra To: Trevor Saunders Cc: tbsaunde+binutils@tbsaunde.org, binutils@sourceware.org Subject: Re: [PATCH] use xstrdup and concat more Message-ID: <20160427061925.GB20333@bubble.grove.modra.org> References: <1461483896-3190-1-git-send-email-tbsaunde+binutils@tbsaunde.org> <20160425130136.GH27353@bubble.grove.modra.org> <20160425135550.GE25520@tsaunders-iceball.corp.tor1.mozilla.com> <20160425145629.GJ27353@bubble.grove.modra.org> <20160426235843.GC9731@ball> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160426235843.GC9731@ball> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00426.txt.bz2 On Tue, Apr 26, 2016 at 07:58:43PM -0400, Trevor Saunders wrote: > On Tue, Apr 26, 2016 at 12:26:29AM +0930, Alan Modra wrote: > > On Mon, Apr 25, 2016 at 09:55:50AM -0400, Trevor Saunders wrote: > > > On Mon, Apr 25, 2016 at 10:31:36PM +0930, Alan Modra wrote: > > > > On Sun, Apr 24, 2016 at 03:44:56AM -0400, tbsaunde+binutils@tbsaunde.org wrote: > > > > > --- a/gas/config/obj-elf.c > > > > > +++ b/gas/config/obj-elf.c > > > > > @@ -949,9 +949,7 @@ obj_elf_section_name (void) > > > > > return NULL; > > > > > } > > > > > > > > > > - name = (char *) xmalloc (end - input_line_pointer + 1); > > > > > - memcpy (name, input_line_pointer, end - input_line_pointer); > > > > > - name[end - input_line_pointer] = '\0'; > > > > > + name = xstrndup (input_line_pointer, end - input_line_pointer); > > > > > > > > > > while (flag_sectname_subst) > > > > > { > > > > > > > > Is this a good idea, here, and in other places where the original uses > > > > memcpy and strlen was not called to find the string length? I'm > > > > thinking that xstrndup will be needlessly calling strlen. > > > > > > I guess that's true, I'm not sure if that really matters though? > > > > Quite possibly not. I wasn't rejecting the patch and didn't see > > anything in the patch that raised a red flag. It was more a case > > of asking you to think about possible performance effects when tidying > > code. Fewer lines of code is not always better. > > Of course ;) I think most of it is around section names which I imagine > isn't very hot. What would you like to do here? How about using a new function, called xmemdup0, say? That way you can happily tidy the source without needing to worry about possible performance effects (and no one needs to worry when reviewing). I'm about to commit the following. inline is handled by ansidecl.h, and the obstack.h macros no longer used. * as.h (inline): Don't define. (__PTR_TO_INT, __INT_TO_PTR): Don't define. (xmemdup0): New inline function. diff --git a/gas/as.h b/gas/as.h index 9ff8bb8..f3e1cf0 100644 --- a/gas/as.h +++ b/gas/as.h @@ -98,13 +98,6 @@ /* Define the standard progress macros. */ #include "progress.h" -/* This doesn't get taken care of anywhere. */ -#ifndef __MWERKS__ /* Metrowerks C chokes on the "defined (inline)" */ -#if !defined (__GNUC__) && !defined (inline) -#define inline -#endif -#endif /* !__MWERKS__ */ - /* Other stuff from config.h. */ #ifdef NEED_DECLARATION_ENVIRON extern char **environ; @@ -144,14 +137,6 @@ extern int vsnprintf(char *, size_t, const char *, va_list); #define bcopy(src,dest,size) memcpy (dest, src, size) #endif -/* Make Saber happier on obstack.h. */ -#ifdef SABER -#undef __PTR_TO_INT -#define __PTR_TO_INT(P) ((int) (P)) -#undef __INT_TO_PTR -#define __INT_TO_PTR(P) ((char *) (P)) -#endif - #ifndef __LINE__ #define __LINE__ "unknown" #endif /* __LINE__ */ @@ -522,6 +507,14 @@ segT subseg_get (const char *, int); const char *remap_debug_filename (const char *); void add_debug_prefix_map (const char *); +static inline void * +xmemdup0 (const void *in, size_t len) +{ + char *out = (char *) xmalloc (len + 1); + out[len] = 0; + return memcpy (out, in, len); +} + struct expressionS; struct fix; typedef struct symbol symbolS; -- Alan Modra Australia Development Lab, IBM