From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87604 invoked by alias); 9 Jun 2017 11:48:46 -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 87573 invoked by uid 89); 9 Jun 2017 11:48:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Anyone X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Jun 2017 11:48:42 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Forcepoint Email with ESMTPS id 4E680A4CE59C0; Fri, 9 Jun 2017 12:48:41 +0100 (IST) Received: from [10.20.78.166] (10.20.78.166) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.294.0; Fri, 9 Jun 2017 12:48:43 +0100 Date: Fri, 09 Jun 2017 11:48:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: Alan Hayward , Yao Qi , "gdb-patches@sourceware.org" , nd Subject: Re: [PATCH 3/11] Add MIPS_MAX_REGISTER_SIZE (4/4) In-Reply-To: Message-ID: References: <3C00280E-37C9-4C0A-9DA6-F3B9DB1A6E8F@arm.com> <86y3v7uf9j.fsf@gmail.com> <0150DDF9-6204-4F4F-99E9-D757C1DBD512@arm.com> <434A7317-C19A-4B53-8CB1-C7B4ACEC7D17@arm.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT X-SW-Source: 2017-06/txt/msg00232.txt.bz2 On Fri, 9 Jun 2017, Pedro Alves wrote: > > I’ve avoided using variable-length arrays because it has the potential to > > break the stack. > > However, here we know that we aren’t going to get a value >8, so maybe in > > this case a VLA would be ok? > > > > Anyone else have an opinion here? > > VLAs are not standard C++, unfortunately. Do we know whether all compilers > we care about support them? It doesn't seem worth it to me to rely > on compiler extensions when we know we're always going to see a size <=8. Hmm, `alloca' then? It used to be used here actually, up till commit d9d9c31f3130 ("MAX_REGISTER_RAW_SIZE -> MAX_REGISTER_SIZE"), . Maciej