* JINMEI Tatuya / [EMAIL PROTECTED]@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.
--
[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
