I've been watching these discussions with interest, as INN uses both of those functions and I've been trying to figure out if I need to worry about these macros. One thing that I'm mostly missing, though, is what benefits a portable program gains from either of these, particularly from accept. For select, I see that it handles systems without fd_set (I personally don't care about any such systems; INN has yet to encounter any that people are still using), but beyond that, if you have fd_set but select expects an int *, isn't passing an fd_set * instead just a compiler warning? I realize that in theory ANSI C permits these pointers to have completely different representations and therefore permits a cast to be meaningful, but are there any systems where this is an issue in practice? And even more so with accept; isn't what type the third argument is just a matter of compiler warnings in practice? Are there systems where accept actually breaks if you use an int * where a socklen_t * or a size_t * was expected? I'm not disagreeing with the macros at all; suppressing warnings is a valid goal, particularly since some vendor compilers are very picky and warnings can be useful for finding real problems. But I'd like to get a feel for the severity of the problems that are really being solved by using these sorts of macros. (I guess this goes back to the general point that right now it's very unclear which of the tests that autoconf provides are actually useful for some "practical" level of portability, and which can be safely ignored for most programs that are already assuming "SunOS and Ultrix or better.") -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
