Date: Thu, 15 Nov 2007 00:55:26 +0100 From: "Heiko Wundram (Beenic)" <wundram@beenic.net> To: freebsd-questions@freebsd.org Subject: Re: Socket programming question Message-ID: <200711150055.27132.wundram@beenic.net> In-Reply-To: <340a29540711141421tda33970q79f85533fb5ba725@mail.gmail.com> References: <340a29540711141421tda33970q79f85533fb5ba725@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200711150055.27132.wundram>