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

[Paul Eggert]

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).