From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48197 invoked by alias); 12 Jun 2017 14:29:20 -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 47889 invoked by uid 89); 12 Jun 2017 14:29:19 -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=learn 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; Mon, 12 Jun 2017 14:29:17 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Forcepoint Email with ESMTP id 47B132ADC483C; Mon, 12 Jun 2017 15:29:16 +0100 (IST) Received: from [10.20.78.192] (10.20.78.192) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.294.0; Mon, 12 Jun 2017 15:29:18 +0100 Date: Mon, 12 Jun 2017 14:29: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="US-ASCII" X-SW-Source: 2017-06/txt/msg00313.txt.bz2 On Fri, 9 Jun 2017, Pedro Alves wrote: > > Hardcoding things, and especially with literals, causes a maintenance > > pain when things change. Bad code elsewhere is not an excuse; besides, > > the other places where `8' is hardcoded are not (buffer) limits, but just > > handle specific register sizes, which are not going to change, and which > > are a completely different matter. > > Perhaps you won't be surprised to learn that I subscribe to the same general > principles. However, I believe that this isn't, in fact, a completely > different matter, because the buffer in question is used to hold the > contents of a structure's address, to either put in a general register, > or in a stack slot, and those (addresses and general registers), unlike FPRs, > aren't expected to grow for a given architecture. Well, apart from being a software bug a buffer overflow is a potential security concern, while an unhandled particular object kind is only a bug. > > So if you find `alloca' unacceptable, > > then the limit has to be a macro, and an assertion check is also due (as > > already proposed), preferably using `sizeof', so that a future change does > > not break it by accident. > > I think a patch like the below is likely to clarify things. > (Builds, but is otherwise untested). LGTM; fairly mechanical. Thanks! Maciej