Re: Proper use of select() parameter nfds?

Matthew Hagerty <mhagerty@voyager.net> writes:

> What erks me about this call is that I have to know what file descriptors are
> and what the largest one I want to use is.  "Technically", for in/out/err your
> are supposed to use defines from a lib supplied with your OS, and for other
> files you make a var of type FILE and assign the return result from fopen()
> (or socket, etc.) to that.

You are confused.  fopen() returns a FILE *, while socket() returns a
descriptor.  

Don't use any stdio calls (fopen(), fprintf(), etc) with select() as
the stdio buffering can screw you up.  

>                            I guess my point is that by having to pass a
> parameter like nfds, it completely removes all abstraction and forces me to
> know something about the kernel internals.

File descriptors are not "kernel internals".  They are part of the
Unix/POSIX API and will not go away.  They're simply a but lower level 
thatn the stdio FILE * interface.

>                                   This is not a problem for me, but
> makes for possibly *very* un-portable code.  What if a file
> descriptor is a structure on anther OS?  I read somewhere once that
> the use of 0,1,2 for the in/out/err was something being frowned on
> since that could change one day, but select() is not helping things
> either.  

I consider it extremely unlikely that the 0,1,2 convention will ever
change, as it would break almost every Unix program out there.

>                Also, I know of no function that returns the highest file
> descriptor I have open for my process.

Yes, you have to keep track of it yourself.  It's a bit annoying.

-Doug
-- 
The rain man gave me two cures; he said jump right in,
The first was Texas medicine--the second was just railroad gin,
And like a fool I mixed them, and it strangled up my mind,
Now people just get uglier, and I got no sense of time...          --Dylan