Socket programming question

[Andrew Falanga]

On Nov 14, 2007 4:55 PM, Heiko Wundram (Beenic) <wundram at beenic.net> wrote:

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

Thanks.  Actually, this suggestion of yours I think does answer my
question.  I was thinking that in my testing program, I would be using
something like that after thinking things through.  Thanks again.

Andy