Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Sep 2004 03:58:05 +0900
From:      JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To:        Thomas Quinot <thomas@FreeBSD.ORG>
Cc:        Hajimu UMEMOTO <ume@FreeBSD.org>
Subject:   Re: freeaddrinfo(NULL)
Message-ID:  <y7visa7h2ki.wl@ocean.jinmei.org>
In-Reply-To: <20040921180746.GB49259@melusine.cuivre.fr.eu.org>
References:  <20040921123016.GA41677@melusine.cuivre.fr.eu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Tue, 21 Sep 2004 20:07:46 +0200, 
>>>>> Thomas Quinot <thomas@FreeBSD.ORG> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7visa7h2ki.wl>