On Nov 14, 2007 4:55 PM, Heiko Wundram (Beenic) <[EMAIL PROTECTED]> wrote:
> Sorry to say that, but it doesn't make sense as it's worded. The
> returned by socket(2) is valid if it's >= 0 (that's the API contract for
> socket(2) C function), and remains valid until the program ends (unless
> close the descriptor with close(2) before your program terminates, in
> case the descriptor first becomes invalid [i.e. EBADF], but might be
> later by another call to socket(2) or open(2), in which case the
> again becomes valid but is associated with another object and possibly
> 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
> a PR.
> Generally, the easy way to query whether a descriptor is valid is by
> 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
> 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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"