Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Oct 1998 15:20:55 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Bruce Evans <bde@zeta.org.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:  <199810110720.PAA19559@spinner.netplex.com.au>
In-Reply-To: Your message of "Sun, 11 Oct 1998 16:24:52 %2B1000." <199810110624.QAA13368@godzilla.zeta.org.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> >> 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.

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?

If we "define" execl*() as not having side effects, it would help.

> >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? :-().

Heh.  Somehow I suspect that language features are going to trickle 
through much sooner.  C++ supports this, doesn't it?

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

> Bruce

Cheers,
-Peter



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?199810110720.PAA19559>