This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 02/19/2016 12:19 PM, Adhemerval Zanella wrote:
And it is a regression only if you consider dynamic allocation an alternative,
It's a regression in that it would break some applications that currently work. An application that is simple (no signal handling, single-threaded, etc.) can invoke programs with many arguments now, but the same application won't work if that patch is installed.
Come to think of it, execlp, posix_spawn, and posix_spawnp can all use malloc, since POSIX does not require them to be async-signal-safe. So you can go back to using malloc for their implementations, when they are given large argument vectors. The only conformance problem here will be execl and execle.
For these two, I suggest a machine-dependent implementation, with the default being something along the lines of the attached (this is totally untested, I'm just trying to give the gist).
A better strategy would be set either hard limits on stack usage in design phase or to focus on enable GLIBC to use a better stack protection mechanism (preferable through compiler assistance).
The latter sounds like a good idea, but is a bigger project and I doubt whether we'd want to wait for that project to be finished before fixing the exec-family problems in question.
Attachment:
execl.c
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |