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