Date: Tue, 21 Sep 2004 23:32:33 +0200 From: Thomas Quinot <thomas@FreeBSD.ORG> To: "JINMEI Tatuya / ?$B?@L@C#:H" <jinmei@isl.rdc.toshiba.co.jp> Cc: Thomas Quinot <thomas@freebsd.org> Subject: Re: freeaddrinfo(NULL) Message-ID: <20040921213233.GA84392@melusine.cuivre.fr.eu.org> In-Reply-To: <y7vfz5bgzda.wl@ocean.jinmei.org> References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> <y7visa7h2ki.wl@ocean.jinmei.org> <20040921190717.GG84228@lucky.net> <y7vfz5bgzda.wl@ocean.jinmei.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* JINMEI Tatuya / ?$B?@L@C#:H, 2004-09-21 :
> (or is valid for freeaddrinfo). It's the caller's responsibility to
> ensure that this is a valid pointer. But consider the case where the
Exactly. And it is the callee's responsibility to enforce the invariants
he expects. If freeaddrinfo did noop in face of a NULL argument, the
programmer could very well *know* that the pointer may be NULL, and
would not bother to check that.
> freeaddrinfo(NULL) segfaults, we found the bug at this point. If
> freeaddrinfo(NULL) does no-op, the latter part of the function is
> executed whereas the assumption isn't met.
Not a problem unless the code after that call does rely on that
assumption, which may or may not be the case. And thus the fact that
freeaddrinfo segfaults in face of a NULL pointer is something
potentially useful in only a very specific case.
> cause a bad effect. But the real point of the bug that led to the
> NULL argument is hidden, which may cause another serious problem in
> some other part of the code.
Well, a segv definitely causes serious trouble to the application as
well.
> function itself seems to work without a problem whereas it actually
> just hides a bug.
You cannot make that assumption! There are many valid scenarios that
could lead to that situation that are not necessarily erroneous.
> not so convincing. I basically talk about a general practice (which I
> personally believe) that it's always better to catch an error than to
> ignore it and the sooner is the better.
I basically talk about a general practice that the system is supposed to
provide mechanism, not policy. :-)
> >> 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 hope I haven't started a flame fest !)
> This statement is too short to tell if it's valid, but I believe
> Segfaulting on freeaddrinfo(NULL) can make something safer for the
> reason I described above. That is, catching a bug earlier *can*
> make a safer result.
In some conditions. But we have to take into account the fact that other
systems do behave differently with a NULL pointer in freeaddrinfo (yes,
I am specicly thinking of Linux and Windows), and we may also want to
take *that* into account and find out how we can offer a consistent
interface to programmers. I also believe that it would be friendlier to
programmers to offer a behaviour more similar to free(3).
> the vast majority supports the idea. However, since the API
> specification is silent on this, I'd then request that the man page
> make an explicit note that the application programmer should be check
> if the argument to freeaddrinfo() is valid because passing a NULL
> pointer may cause an unexpected result, including segfaulting, on
> other systems.
That sounds perfectly fair to me.
Thomas.
--
Thomas.Quinot@Cuivre.FR.EU.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040921213233.GA84392>