From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cyan.elm.relay.mailchannels.net (cyan.elm.relay.mailchannels.net [23.83.212.47]) by sourceware.org (Postfix) with ESMTPS id B7F9A3857805 for ; Thu, 25 Feb 2021 05:28:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B7F9A3857805 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 887703624CE; Thu, 25 Feb 2021 05:28:02 +0000 (UTC) Received: from pdx1-sub0-mail-a53.g.dreamhost.com (100-96-11-27.trex.outbound.svc.cluster.local [100.96.11.27]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0FCAF3627CE; Thu, 25 Feb 2021 05:28:02 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a53.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.11.27 (trex/6.0.2); Thu, 25 Feb 2021 05:28:02 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Macabre-Wipe: 474dd1935bbda16f_1614230882318_2942515617 X-MC-Loop-Signature: 1614230882318:897094022 X-MC-Ingress-Time: 1614230882317 Received: from pdx1-sub0-mail-a53.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a53.g.dreamhost.com (Postfix) with ESMTP id CB08D7E69A; Wed, 24 Feb 2021 21:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gotplt.org; h=subject:to :cc:references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=gotplt.org; bh=vHR8zh TtgmOnslaowRB7LPI6cNk=; b=SdmDjgEruCk4ZbE0THhNoUs43gzARzCyekLIKc N7yvTAC5WxrFdUdyb5KoNyPrLH00kri5CyUPvb07HStpkhikczWdqUaD9H4jTx8T 9KpKpUmoDeY9zpyijwJbj1AqFEGDfwo8yGXFi2YYv3oHfSj/f3OQrDmcZ5iAUp4r 38YgM= Received: from [192.168.1.111] (unknown [1.186.101.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a53.g.dreamhost.com (Postfix) with ESMTPSA id F1D1F7E3AB; Wed, 24 Feb 2021 21:27:57 -0800 (PST) Subject: Re: 'trusted and reasonably structured' regular expressions To: Paul Eggert , Zack Weinberg Cc: Florian Weimer , Siddhesh Poyarekar via Libc-alpha , Joseph Myers References: <2152f614-0003-8dcf-f5cd-2d12c4e77e28@gotplt.org> <72abad60-65ab-10e9-45fb-748fdcd310db@gotplt.org> <31c6cdcf-7882-6ec2-e709-2e05cbeb6b76@gotplt.org> <2c252ede-ec7c-0d49-3e8e-ee217a830b38@cs.ucla.edu> X-DH-BACKEND: pdx1-sub0-mail-a53 From: Siddhesh Poyarekar Message-ID: Date: Thu, 25 Feb 2021 10:57:52 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <2c252ede-ec7c-0d49-3e8e-ee217a830b38@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3029.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 05:28:06 -0000 On 2/25/21 10:23 AM, Paul Eggert wrote: > On 2/24/21 7:15 PM, Siddhesh Poyarekar wrote: >> * Stack overflows due to recursion when processing patterns >> >> Crashes, user controlled unbounded alloca, > > I don't understand why user-controlled unbounded alloca is in a > different category from user-controlled unbounded recursion. In both > cases you exhaust the stack. So I suggest removing "user controlled > unbounded alloca,". I wanted to make the distinction between repeated stack allocations vs a single unbounded allocation due to user input, wherein the latter ought to be forbidden in all of glibc. Would you agree with that or do you think we should stay away from allocation related failures altogether? Siddhesh