From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16094 invoked by alias); 7 Dec 2009 20:25:36 -0000 Received: (qmail 15997 invoked by uid 22791); 7 Dec 2009 20:25:35 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Dec 2009 20:25:29 +0000 Received: from spaceape9.eur.corp.google.com (spaceape9.eur.corp.google.com [172.28.16.143]) by smtp-out.google.com with ESMTP id nB7KPQjY021014 for ; Mon, 7 Dec 2009 20:25:26 GMT Received: from ewy23 (ewy23.prod.google.com [10.241.103.23]) by spaceape9.eur.corp.google.com with ESMTP id nB7KPGuU017854 for ; Mon, 7 Dec 2009 12:25:24 -0800 Received: by ewy23 with SMTP id 23so4040177ewy.4 for ; Mon, 07 Dec 2009 12:25:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.93.17 with SMTP id k17mr2542012wef.31.1260217523041; Mon, 07 Dec 2009 12:25:23 -0800 (PST) In-Reply-To: <200912072009.nB7K9moj000406@greed.delorie.com> References: <20091207172641.398198456F@ruffy.mtv.corp.google.com> <200912072009.nB7K9moj000406@greed.delorie.com> Date: Mon, 07 Dec 2009 20:25:00 -0000 Message-ID: Subject: Re: [RFA] save/restore environ in libiberty pex_unix_exec_child From: Doug Evans To: DJ Delorie Cc: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-12/txt/msg00093.txt.bz2 On Mon, Dec 7, 2009 at 12:09 PM, DJ Delorie wrote: > > If the child assignment truly clobbers the parent, won't the parent's > assignment clobber the child? > > If it's portable enough, using exevpe/execve instead of execvp/execv > would be preferred. The context is a child running under vfork. While the linux man page says one cannot assume, for example, that the parent is blocked until the child execs/exits, it would be odd if in implementations where the parent is not blocked that assignments in the parent clobbered the child. s/odd/broken/ even. :-) [from man vfork] CONFORMING TO 4.3BSD, POSIX.1-2001. The requirements put on vfork() by the standards are weaker than those put on fork(2), so an implementation where the two are synonymous is compliant. In particular, the programmer cannot rely on the parent remaining blocked until a call of execve(2) or _exit(2) and cannot rely on any specific behavior with respect to shared memory. I don't disagree re. execve, *if* it's portable enough. I wasn't prepared to investigate the full gamut of portability issues for this. Some thought may have gone into what's there now (maybe, maybe not, but I err'd on the side of being cautious). My patch seems like a straightforward fix to what's there now.