Am Mittwoch, 14. November 2007 23:21:43 schrieb Andrew Falanga:
> My question has to do with how someone would find out if a call to
> socket(2) actually produced a socket. I know that the API works, I've
> programmed with it many times, but is there a way to find out if 's'
> returned by socket(2) is actually valid in whatever kernel structure it is
> stored? I understand that I may have the process entirely mixed up. But
> it seems to me that the socket is somehow known to the kernel and I should
> be able to query the kernel somehow and discover if it is valid.
> Let me know if my question doesn't make sense as worded and I'll try to
> explain myself better. Another question related to this one, would someone
> in this list know where the source code is, in the system source tree, for
> the select call?
Sorry to say that, but it doesn't make sense as it's worded. The descriptor
returned by socket(2) is valid if it's >= 0 (that's the API contract for the
socket(2) C function), and remains valid until the program ends (unless you
close the descriptor with close(2) before your program terminates, in which
case the descriptor first becomes invalid [i.e. EBADF], but might be reused
later by another call to socket(2) or open(2), in which case the descriptor
again becomes valid but is associated with another object and possibly also
with another type of object [file/pipe vs. socket]).
That's the API-contract that's specified in POSIX, and to which FreeBSD
sticks. As an application programmer, you can (and have to) rely on this
behaviour; any derivation from this is a kernel bug, and should be posted as
Generally, the easy way to query whether a descriptor is valid is by simply
calling the respective function you want to execute on it, and if that
returns errno = EBADF, then you know that the descriptor is invalid. In case
it returns something else, it just tells you that the descriptor is valid,
but doesn't tell you whether the descriptor is really associated with what
you think it is. But if you follow the flow of control in the program, you
should be able to make out where the descriptor is created and how it's
modified, and thus be able to deduce (under the condition that the kernel
sticks to POSIX specifications) what the state of the descriptor is at the
time of usage.
Hope this helps!
Product & Application Development
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"