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 
a PR.

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!

-- 
Heiko Wundram
Product & Application Development
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to