Date: Sun, 11 Oct 1998 18:46:54 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, peter@netplex.com.au Cc: bde@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/gen popen.c Message-ID: <199810110846.SAA20497@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >I suspect this has come about because of a change of implementation in
>> >exec*(). I suspect they used to do something like:
>> >
>> >execl(arg1, arg2)
>> >{
>> > execve(arg1, &arg1, environ);
>> >}
>> >
>> >... but since prototypes has been changed to use malloc etc and build an
>> >array by sucking in args via va_arg() etc.
>>
>> ANSI should tell you that you can't do the above if a correct (varadic)
>> prototype is in scope. NetBSD has ifdefs to do it anyway on arches where
>> the varadic args are known to be on the stack.
>
>Well, can we do it too? Or move it to the MD part of libc source
>(eg: libc/i386/gen/execl.c) and the same on other systems that can do it?
This is more of a micro-optimization than I like.
>If we "define" execl*() as not having side effects, it would help.
We'll have to make it work to avoid fixing dusty decks, but it shouldn't
be documented since it isn't portable. vfork.2 only mentions execve()
and other pure syscalls as being safe.
>> We could just allocate ARG_MAX bytes on the stack. This has the same
>> problems as alloca() and VLAs - stack memory isn't quite free. It
>> may be better because it crashes more deterministically.
>
>We could use this method as a fallback for systems that we can't pull
>varadic args off the stack.
More ifdefs :-(. The ARG_MAX limit exists mainly so the kernel doesn't
need to do complicated or large allocations. Our kernel just allocates
ARG_MAX (plus PAGE_SIZE) bytes of vm, and it knows more about allocation
than the library.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810110846.SAA20497>