freeaddrinfo(NULL)

[Thomas Quinot]

* JINMEI Tatuya / ?$B?@L at 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 at Cuivre.FR.EU.ORG