>>>>> "Steve" == Steve Robbins <[EMAIL PROTECTED]> writes:
Steve> Thanks, Akim.
Hi Steve!
Steve> I think what Lars sent out most recently was a *NEW* macro,
Steve> which we have been calling AC_FUNC_SELECT. The name is up for
Steve> discussion of course, but it should be different from the
Steve> preceeding, IMHO, as it serves a different purpose.
I understood this, but my claim is that this is mostly the same core,
with just a different interface. The core was simplified and is now
much more readable in CVS Autoconf. I was asking for the new macro to
be adjusted to the style of the macro in Autoconf.
Because the core is essentially the same, I started from the old macro
and changed it incrementally, but in the long run, if you think it
ought to be name AC_FUNC_SELECT, let's go for it. I'm all for
simplification of the interface.
Steve> fd_set_size_t num_fds; fd_set read_fds;
Steve> select( num_fds, &read_fds, NULL, NULL, 0 );
Thanks for the explanations!
Steve> The type for arguments 2-4 is frequently named "fd_set". So my
Steve> idea is to always use that "type", by defining it if not
Steve> already defined in the system headers. This is in the same
Steve> spirit as defining "pid_t", "uid_t", and the like.
Steve> I'm told by Lars that HP-UX defines the type `fd_set', but
Steve> doesn't use it for select arguments 2-4! (It uses 'int *'
Steve> instead) It turns out, though, that the type 'fd_set' is used
Steve> for the FD_SET() macros. (!) This means that whatever fd_set
Steve> is defined as, it must be large enough to hold a set of file
Steve> descriptor flags. Hence we should be able to use that type in
Steve> args 2-4 of select(), anyway (is this a dangerous
Steve> assumption??). Code doing so should compile and work fine, but
Steve> you might get a "type mismatch" diagnostic from the compiler.
Steve> Thus, for the extra careful, we define a symbol called
Steve> SELECT_FD_SET_CAST to be either: (a) empty, in the common case
Steve> that args 2-4 are 'fd_set *' and thus need no cast, or (b)
Steve> something like '(int *)' for weirdos that use fd_set, but
Steve> prototype select() with 'int *' as args 2-4.
It doesn't sound right. I must confess I never faced the case of the
type being defined to something else than what was expected, so I
don't know the official strategy, but this one is not right.
Paul may have suggestions to make?
Personally I would say you should go with a new type name. Since you
are `_t' arg1, why don't you fd_set_t the 2-4 too?
Steve> For the extra-careful, the code fragment above becomes
Steve> fd_set_size_t num_fds; fd_set read_fds;
Steve> select( num_fds, SELECT_FD_SET_CAST &read_fds, NULL,
Steve> NULL, 0 );
Gross! Let's have
#if defined SELECT_FD_SET_CAST
# define select(a, b, c, d, e) \
select((a), SELECT_FD_SET_CAST (b), (c), (d), (e))
#endif
instead :)
Steve> I also suggest that the macro call AC_CHECK_FUNCS(select) at
Steve> the beginning and fail with a useful diagnostic (e.g. "required
Steve> function select not found") if there is no select() function.
Nope, rather it should AC_CHECK_FUNCS it, but let the author of
configure.in die if he wishes.
Steve> Finally, there is the question of what to do if none of the
Steve> possibilities pan out. The macro loops through several
Steve> possibilities each for arg1, arg234 and arg5. If none of the
Steve> test programs compile, all versions of this macro that I have
Steve> seen choose a "safe default value" of 'int', 'int *', and
Steve> 'struct timeval *'. However, this combination is one of the
Steve> ones explicitly tested. And it failed. So it ain't a "safe"
Steve> value at all! I suggest the macro fail loudly if nothing
Steve> works.
No problem with me with complaining, but I don't think it should die
by itself.
Akim
