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 > 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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"