From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 18:58:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B12F016A4D8; Tue, 21 Sep 2004 18:58:06 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5966343D5D; Tue, 21 Sep 2004 18:58:04 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:b975:fedf:fb7f:f7d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 15C4215263; Wed, 22 Sep 2004 03:58:01 +0900 (JST) Date: Wed, 22 Sep 2004 03:58:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Quinot In-Reply-To: <20040921180746.GB49259@melusine.cuivre.fr.eu.org> References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: Hajimu UMEMOTO Subject: Re: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2004 18:58:06 -0000 >>>>> On Tue, 21 Sep 2004 20:07:46 +0200, >>>>> Thomas Quinot said: >> Because, the behavior of freeaddrinfo (NULL) is undefined in RFC 2553 >> nor RFC 3493. Having such an assumption is a potentially bug and >> lose portability. > Would there be any significant drawback for conforming applications > if we made our best to deploy a safety net againt buggy user programs > by not segfaulting in this case? As Umemoto-san said, if we made freeaddrinfo(NULL) "safe", the application programmers might tend to rely on the "safety net" and the uncareful coding style. This can be worse than the segfault here, because the reason for the NULL argument might be a bug in the program, and, as a result of hiding the bug by making freeaddrinfo(NULL) "safe", it might cause much more serious effects later in the program. In my understanding, this kind of discussion has always been controversial; whether we want to make more explicit errors (even if those are segfaults), or whether we want to "spoil" bad programmers by making the library interface "safe". I personally prefer the former idea. Ideally, freeaddrinfo() should have provided a return value which is a binary "success" or "fail", so that the application programmers can check the value to be sure that they pass a valid pointer. With the fact that freeaddrinfo() is actually a void function, however, I'd rather keep the current behavior (i.e., segfaulting) as an evil error indication. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp