From owner-freebsd-arch@FreeBSD.ORG Wed May 23 03:00:29 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76AFE16A41F for ; Wed, 23 May 2007 03:00:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 158E713C465 for ; Wed, 23 May 2007 03:00:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l4N30Dvs065018; Tue, 22 May 2007 21:00:14 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 22 May 2007 23:00:26 -0400 (EDT) Message-Id: <20070522.230026.1611667537.imp@bsdimp.com> To: peterjeremy@optushome.com.au From: "M. Warner Losh" In-Reply-To: <20070517094445.GD1149@turion.vk2pj.dyndns.org> References: <86fy5wkim5.fsf@dwp.des.no> <20070517094445.GD1149@turion.vk2pj.dyndns.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 22 May 2007 21:00:15 -0600 (MDT) Cc: des@des.no, antinvidia@gmail.com, freebsd-arch@freebsd.org Subject: Re: A problem with the select(2) interface X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2007 03:00:29 -0000 In message: <20070517094445.GD1149@turion.vk2pj.dyndns.org> Peter Jeremy writes: : On 2007-May-16 15:23:14 +0200, Dag-Erling Smrgrav wrote: : >MQ writes: : >> No, that is not what I want. I think we'd better add a comments that : >> we *DO NOT WRITE TO THAT ADDRESS*, what the manual describes is that : >> there may be some platforms which write to that address. It's not the : >> same thing. : > : >Some platforms update the timeval and some don't, so portable : >applications must simply assume that its contents are undefined after : >the select(2) call. It can not be relied on to contain either the : >initial value nor the amount of time remaining. Thus your proposed : >change is pointless. : : I disagree. The FreeBSD man pages should document the behaviour of : FreeBSD. It's all very nice stating that SUSv2 allows a system to : modify the value passed as timeout but (IMNSHO), it is more important : to document what FreeBSD actually does. : : I agree that a _portable_ application must assume that timeout will : be undefined but that's no reason for refusing to document what : FreeBSD's behaviour actually is. : : There are two situations where the actual behaviour matters: : 1) Porting a random application that assumes specific behaviour for : select(). I need to know how FreeBSD behaves to know whether I : need to patch the code or not. : 2) I'm writing code that is specifically for FreeBSD. If I know : timeout will not change, I can optimise the code to avoid having to : re-initialise timeout before each select call. Index: select.2 =================================================================== RCS file: /cache/ncvs/src/lib/libc/sys/select.2,v retrieving revision 1.33 diff -u -r1.33 select.2 --- select.2 9 Jan 2007 00:28:15 -0000 1.33 +++ select.2 23 May 2007 03:00:14 -0000 @@ -222,3 +222,6 @@ by the .Fn select system call. +.Fx +does not modify the return value, which can cause problems for applications +ported from other systems.