From owner-cvs-all Sun Oct 11 00:48:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA29189 for cvs-all-outgoing; Sun, 11 Oct 1998 00:48:57 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA29174; Sun, 11 Oct 1998 00:48:35 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id PAA19559; Sun, 11 Oct 1998 15:20:56 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199810110720.PAA19559@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Bruce Evans cc: bde@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/gen popen.c In-reply-to: Your message of "Sun, 11 Oct 1998 16:24:52 +1000." <199810110624.QAA13368@godzilla.zeta.org.au> Date: Sun, 11 Oct 1998 15:20:55 +0800 From: Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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