From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <fw@deneb.enyo.de>
Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21])
 by sourceware.org (Postfix) with ESMTPS id A6C4F3857C57
 for <libc-alpha@sourceware.org>; Sun,  9 Aug 2020 12:38:20 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A6C4F3857C57
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=deneb.enyo.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de
Received: from [172.17.203.2] (helo=deneb.enyo.de)
 by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 id 1k4kaU-0005Rg-Ur; Sun, 09 Aug 2020 12:38:06 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.92)
 (envelope-from <fw@deneb.enyo.de>)
 id 1k4kaU-0005eu-Rt; Sun, 09 Aug 2020 14:38:06 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Xiaoming Ni <nixiaoming@huawei.com>, libc-alpha@sourceware.org,
 drepper.fsp@gmail.com, roland@gnu.org, carlos@redhat.com,
 adhemerval.zanella@linaro.org, wangle6@huawei.com, yukeji@huawei.com
Subject: Re: [PATCH v2] stdlib: realpath use malloc replace __alloca to reduce
 stack overflow risks [BZ #26341]
References: <20200807101601.61670-1-nixiaoming@huawei.com>
 <059aea74-2976-c16a-0a6d-fbde2123ac87@cs.ucla.edu>
 <27f372e4-ec8d-340e-e12b-83b2cbca1c5b@huawei.com>
 <22af5291-1e5b-d1ee-d333-7bed39402996@cs.ucla.edu>
Date: Sun, 09 Aug 2020 14:38:06 +0200
In-Reply-To: <22af5291-1e5b-d1ee-d333-7bed39402996@cs.ucla.edu> (Paul Eggert's
 message of "Sun, 9 Aug 2020 01:44:12 -0700")
Message-ID: <87h7tc0zbl.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Aug 2020 12:38:22 -0000

* Paul Eggert:

> On 8/8/20 1:54 AM, Xiaoming Ni wrote:
>> To avoid possible stack overflow risks (the remaining stack space is uncertain 
>> when realpath is called), should we sacrifice some efficiency and reduce the 
>> stack space usage? Use malloc instead of alloca (4k+4k).
>
> 8 KiB of stack in a non-recursive I/O routine is not that big a deal. I don't 
> see why we would need to worry about that.

I have seen a report that the temporary buffer in vfprintf on an
unbuffered stream causes crashes because after a hardware upgrade, the
available stack space was insufficient.  That on-stack buffer is 8 KiB
as well.