From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66850 invoked by alias); 30 Nov 2018 13:56:06 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 66155 invoked by uid 89); 30 Nov 2018 13:56:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=unavailable version=3.3.2 spammy= X-HELO: sam.airs.com Received: from sam.airs.com (HELO sam.airs.com) (64.13.145.90) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Nov 2018 13:56:02 +0000 Received: (qmail 43825 invoked by uid 10); 30 Nov 2018 13:56:00 -0000 Received: (qmail 6907 invoked by uid 500); 30 Nov 2018 13:55:52 -0000 Mail-Followup-To: jakub@redhat.com, gcc-patches@gcc.gnu.org, binutils@sourceware.org, matz@gcc.gnu.org, sgayou@redhat.com, jason@redhat.com, nickc@redhat.com From: Ian Lance Taylor To: Nick Clifton Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, binutils@sourceware.org, matz@gcc.gnu.org, sgayou@redhat.com, jason@redhat.com Subject: Re: RFA/RFC: Add stack recursion limit to libiberty's demangler References: <87muprdko7.fsf@redhat.com> <20181130084211.GX12380@tucnak> <173817ca-0aa0-e1a2-6725-37e079ead545@redhat.com> Date: Fri, 30 Nov 2018 13:56:00 -0000 In-Reply-To: <173817ca-0aa0-e1a2-6725-37e079ead545@redhat.com> (Nick Clifton's message of "Fri, 30 Nov 2018 10:26:58 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-11/txt/msg02571.txt.bz2 Nick Clifton writes: > I did consider just having a fixed limit, that the user cannot change, but > I thought that this might be rejected by reviewers. (On the grounds that > different limits are appropriate to different execution environments). > Note - enabling or disabling the recursion limit is controlled by a separate > feature of the proposed patch, ie the new DMGL_RECURSE_LIMIT flag in the > options field of the cplus_demangleXXX() functions. But there is not enough > room in the options field to also include a recursion limit value. I think it would be fine to have a large fixed limit plus a flag to disable the limit. I can't think of any reason why a program would want to change the limit unless it has complete trust in the symbols it is demangling, and in that case it may as well simply disable the limit. Ian