[PATCH] Improve execl* functions
Federico Terraneo
fede.tft@hotmail.it
Wed Jan 29 08:53:11 GMT 2025
On 27/01/25 18:26, Corinna Vinschen wrote:
> But it would still be nice to have a more dynamic solution which doesn't
> need ARG_NUM_MAX.
Hi Corinna,
I spent some time into it, and it's more complicated than I wanted, but
I have a patch in this direction nonetheless, that replaces the previous
patch proposal.
The complexity is caused by POSIX.1-2008 which as far as I could tell
requires execl* functions to be callable from signal handlers, while
malloc isn't. That leaves alloca as the only way I can think of to lift
the argument number limitation.
The issue is, newlib targets also microcontroller targets where there's
no virtual memory and stacks are small (our Miosix OS is one example),
thus unbounded stack allocation (or just large stack allocations like
the 1024bytes array in the current version of the execl* code) cause
stack overflows and undefined behavior.
Thus I propose the attached patch that by default uses alloca but allows
individual targets to define _EXECL_USE_MALLOC if in their use case the
risk of stack overflows and consequent undefined behavior is a more
pressing requirement than the corner case of allowing execl* calls from
signal handlers.
Even with the default alloca implementation, the patched code uses
*less* stack than the current code when execl* functions are called with
less that 256 arguments, and on platforms where the stack can grow (i.e,
when virtual memory is available) it entirely avoids the stack buffer
overflow that was present in the current code, so I think it's an
overall improvement.
Best regards,
Federico Terraneo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Lift-256-arg-limit-in-exec.patch
Type: text/x-patch
Size: 3959 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20250129/02dd297f/attachment.bin>
More information about the Newlib
mailing list