From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3672 invoked by alias); 8 Mar 2004 02:37:38 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 3655 invoked from network); 8 Mar 2004 02:37:38 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 8 Mar 2004 02:37:38 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 0BFE7357B; Sun, 7 Mar 2004 18:37:36 -0800 (PST) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id i282baOi004327; Sun, 7 Mar 2004 18:37:36 -0800 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id i282bXG6004322; Sun, 7 Mar 2004 18:37:33 -0800 Date: Mon, 08 Mar 2004 02:37:00 -0000 Message-Id: <200403080237.i282bXG6004322@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Ulrich Drepper Cc: Andreas Schwab , libc-hacker@sources.redhat.com Subject: Re: getpid/vfork broken In-Reply-To: Ulrich Drepper's message of Sunday, 7 March 2004 18:28:06 -0800 <404BDA36.6000202@redhat.com> X-Zippy-Says: .. the MYSTERIANS are in here with my CORDUROY SOAP DISH!! X-SW-Source: 2004-03/txt/msg00018.txt.bz2 The new specification for vfork where you can't even call dup2 is very close to useless. The origin of vfork and true standard for its behavior that applications have been written for is 4.2BSD, where simple system calls were always safe, and getpid has always been the simplest system call. The modern BSD specification remains that the address space is shared, with all that entails, but since getpid has never relied on data contents in the address space before, citing that as license to make it do the wrong thing is dubious at best. Since the useless specification has been enshrined in POSIX, where vfork in fact never belonged at all, it is likely that every historical program will be broken and people will just have to adapt to giving up vfork entirely. Progress.