Date: Sun, 11 Oct 1998 16:24:52 +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: <199810110624.QAA13368@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> More vfork breakage: vfork is used in about 50 programs in /usr/src.
>> It is misused in all 7 programs that I looked at:
>...
>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.
>IMHO, it's bad form for exec* to call malloc. I've been burned before with
>exec() calls mysteriously failing that turned out to be malloc corruption.
>The implementation would be better to use something else. Since we
>presently depend on the gcc environment, we could use it's extensions...
Its extensions.
>execl()
>{
> int count;
> char **argv;
>
> count = (args by walking through the va_list with va_arg());
> .. and rest of exec processing..
> {
> char *newargv[count + 1];
This extension (variable length arrays) will be in C9x. I expect C9x
will take longer to become normal than C89 (30 years instead of only
20? :-().
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.
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?199810110624.QAA13368>