Re: [PATCH v2] stdlib: realpath use malloc replace __alloca to reduce stack overflow risks [BZ #26341]

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 09/08/2020 14:22, Paul Eggert wrote:
> On 8/9/20 5:38 AM, Florian Weimer wrote:
>> 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.
> 
> I have no doubt that there are more bug reports about stack overflows "caused" by vfprintf's 8 KiB stack than about those "caused" by getchar's 2 KiB stack. But this doesn't mean we should worry overmuch about these small stack allocations. It's a fact of life that library routines use a small amount of stack space, and on today's processors 8 KiB in a leaf I/O function counts as "small" even in multithreaded apps. We shouldn't waste valuable development time (or user CPU time) trying to shrink such a function's stack space further.
> 
> It's easy to shrink 164 KiB (as in the original bug report) down to 8 KiB, so let's do that. The need to shrink stack further does not outweigh the need to avoid pressuring the memory allocator and worrying about leaks, so let's quit while we're ahead.
> 
> If (despite my advice) there is a push to shrink the stack space below 8 KiB, at the very least we should introduce no new call to malloc when all processing can be done in a single buffer containing only PATH_MAX bytes (which describes the overwhelming majority of real-world cases).

Could we remove alloca as well? We can make 4k stack usage on most cases use the
extra 4k only where link are seeing the path.