From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67911 invoked by alias); 1 Dec 2015 16:51:26 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 67889 invoked by uid 89); 1 Dec 2015 16:51:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-io0-f170.google.com Received: from mail-io0-f170.google.com (HELO mail-io0-f170.google.com) (209.85.223.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 01 Dec 2015 16:51:24 +0000 Received: by ioc74 with SMTP id 74so15644566ioc.2; Tue, 01 Dec 2015 08:51:22 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.129.82 with SMTP id c79mr30335643iod.95.1448988682531; Tue, 01 Dec 2015 08:51:22 -0800 (PST) Received: by 10.36.200.70 with HTTP; Tue, 1 Dec 2015 08:51:22 -0800 (PST) In-Reply-To: References: <1448974501-30981-1-git-send-email-rep.dot.nop@gmail.com> <1448974501-30981-2-git-send-email-rep.dot.nop@gmail.com> Date: Tue, 01 Dec 2015 16:51:00 -0000 Message-ID: Subject: Re: [PATCH] Derive interface buffers from max name length From: Bernhard Reutner-Fischer To: Janne Blomqvist Cc: Fortran List , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00011.txt.bz2 On 1 December 2015 at 15:52, Janne Blomqvist wrote: > On Tue, Dec 1, 2015 at 2:54 PM, Bernhard Reutner-Fischer > wrote: >> These three function used a hardcoded buffer of 100 but would be better >> off to base off GFC_MAX_SYMBOL_LEN which denotes the maximum length of a >> name in any of our supported standards (63 as of f2003 ff.). > > Please use xasprintf() instead (and free the result, or course). One > of my backburner projects is to get rid of these static symbol > buffers, and use dynamic buffers (or the symbol table) instead. We > IIRC already have some ugly hacks by using hashing to get around > GFC_MAX_SYMBOL_LEN when handling mangled symbols. Your patch doesn't > make the situation worse per se, but if you're going to fix it, lets > do it properly. I see. /scratch/src/gcc-6.0.mine/gcc/fortran$ git grep "^[[:space:]]*char[[:space:]][[:space:]]*[^[;[:space:]]*\[" | wc -l 142 /scratch/src/gcc-6.0.mine/gcc/fortran$ git grep "xasprintf" | wc -l 32 What about memory fragmentation when switching to heap-based allocation? Or is there consensus that these are in the noise compared to other parts of the compiler? BTW: $ git grep APO io.c: static const char *delim[] = { "APOSTROPHE", "QUOTE", "NONE", NULL }; io.c: static const char *delim[] = { "APOSTROPHE", "QUOTE", "NONE", NULL }; > Ok for GCC 7 stage1 with these changes. I don't think it's worth > putting it into GCC 6 at this point anymore, unless this is actually > fixing some bugs that are visible to users? Not visible, no, can wait easily.