Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757508AbZAMWic (ORCPT ); Tue, 13 Jan 2009 17:38:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755114AbZAMWiW (ORCPT ); Tue, 13 Jan 2009 17:38:22 -0500 Received: from fk-out-0910.google.com ([209.85.128.184]:25008 "EHLO fk-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751991AbZAMWiV (ORCPT ); Tue, 13 Jan 2009 17:38:21 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=gfszGMZv5qqOe1XLTJyD5YbpGBEKNZBBw7niGitmzNXIRzy0jaVIQhp7LkqLpLG/lj jc/PgmiHd0pzl4OHQcyxlgAySLHCyc3fmOvVnuaJZHpPD8vagzYQuwlRWaS1q7pGZ6MZ px7+UA/fivyifYkZAzEqg+xZHV7D6H8tufiNQ= Message-ID: Date: Wed, 14 Jan 2009 11:38:18 +1300 From: "Michael Kerrisk" Reply-To: mtk.manpages@gmail.com To: "Roland McGrath" Subject: waitid() return value strangeness when infop is NULL Cc: "kernel list" , "Ulrich Drepper" , "Vegard Nossum" , "linux-man@vger.kernel.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2088 Lines: 58 [Resend with right LKML address.] Hello Roland, Vegard sent me a report of a possible bug in the waitid(2) man page, but on closer examination, the issue seems to be in the waitid() system call. POSIX.1 says of waitid(): RETURN VALUE If WNOHANG was specified and there are no children to wait for, 0 shall be returned. If waitid() returns due to the change of state of one of its children, 0 shall be returned. Otherwise, -1 shall be returned and errno set to indicate the error. The Linux waitid() follows this behavior, as long as infop is not NULL, which is what POSIX requires: The application shall ensure that the infop argument points to a siginfo_t structure. However, Linux's waitid() does permit infop to be NULL. But in this case, a successful call returns the PID of the waited-for child. Thinking about it, I suppose there is a rationale for doing this, since otherwise the caller of waitid() has no way of obtaining the PID of the waited-for child. Anyway, this behavior should either be documented, or "fixed" (i.e., change waitid() to return 0 on success even if infop is NULL). So, some questions: a) Is it intentional to support the infop==NULL case for waitid() -- rather than simply giving an error return? b) If so, what is the rationale for supporting this feature? c) If the the answer a) is "yes", is it intentional for waitid(idtype,id,NULL,options) to return the PID of the child, rather than returning 0? I'll post a test program in a follow-up message. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/