On 11 Jul 2000, Akim Demaille wrote:
>
> For convenience, here is the macro which corresponds to the patch I
> sent.
>
> # AC_FUNC_SELECT_ARGTYPES
> # -----------------------
> # Determine the correct type to be passed to each of the `select'
> # function's arguments, and define those types in `SELECT_TYPE_ARG1',
> # `SELECT_TYPE_ARG234', and `SELECT_TYPE_ARG5'.
> AC_DEFUN([AC_FUNC_SELECT_ARGTYPES],
[ ... ]
Thanks, Akim.
I think we're talking at cross purposes here.
You've reimplemented/simplified the *ORIGINAL* macro, named
AC_FUNC_SELECT_ARGTYPES. That macro had a few shortcomings, the largest
being that while it defines casts for the select() argument types, there
is no portable way to actually *declare* the parameters. See the thread
in the autoconf archives starting at
http://sources.redhat.com/ml/autoconf/1999-01/msg00035.html
I think what Lars sent out most recently was a *NEW* macro, which we have
been calling AC_FUNC_SELECT. The name is up for discussion of course, but
it should be different from the preceeding, IMHO, as it serves a different
purpose.
The intent is that using this macro is enough to get all the relevant info
about the select() function call. Here is what I think the proposed
AC_FUNC_SELECT macro should do. Once we're agreed on this, we can work
out an elegant implementation.
We need to figure out the argument types.
Argument 5 is --- as far as I can tell --- always 'struct timeval *' or
'const struct timeval *'. For code that uses select(), you needn't care
whether it is prototyped with 'const' or not, right? So nothing needs to
be defined for type type of argument 5.
The type for arguments 2-4 is frequently named "fd_set". So my idea is to
always use that "type", by defining it if not already defined in the
system headers. This is in the same spirit as defining "pid_t", "uid_t",
and the like. There is a small wrinkle that I'll explain below.
Argument 1 is the most troublesome. There appears to be a wide variety of
different types in use: 'int' 'size_t' 'unsigned long' 'unsigned'. I don't
know of any typedef for the first argument to select(), so I made one up:
"fd_set_size_t". If you have a better suggestion, I'd love to hear it.
A typical code fragment for calling select() would be
fd_set_size_t num_fds;
fd_set read_fds;
select( num_fds, &read_fds, NULL, NULL, 0 );
As I said, there is a wrinkle with arguments 2-4. I'm told by Lars that
HP-UX defines the type `fd_set', but doesn't use it for select arguments
2-4! (It uses 'int *' instead) It turns out, though, that the type
'fd_set' is used for the FD_SET() macros. (!) This means that whatever
fd_set is defined as, it must be large enough to hold a set of file
descriptor flags. Hence we should be able to use that type in args 2-4 of
select(), anyway (is this a dangerous assumption??). Code doing so should
compile and work fine, but you might get a "type mismatch" diagnostic from
the compiler.
Thus, for the extra careful, we define a symbol called SELECT_FD_SET_CAST
to be either: (a) empty, in the common case that args 2-4 are 'fd_set *'
and thus need no cast, or (b) something like '(int *)' for weirdos that
use fd_set, but prototype select() with 'int *' as args 2-4.
For the extra-careful, the code fragment above becomes
fd_set_size_t num_fds;
fd_set read_fds;
select( num_fds, SELECT_FD_SET_CAST &read_fds, NULL, NULL, 0 );
I also suggest that the macro call AC_CHECK_FUNCS(select) at the beginning
and fail with a useful diagnostic (e.g. "required function select not
found") if there is no select() function.
Finally, there is the question of what to do if none of the possibilities
pan out. The macro loops through several possibilities each for arg1,
arg234 and arg5. If none of the test programs compile, all versions of
this macro that I have seen choose a "safe default value" of 'int', 'int
*', and 'struct timeval *'. However, this combination is one of the ones
explicitly tested. And it failed. So it ain't a "safe" value at all! I
suggest the macro fail loudly if nothing works.
Comments?
-Steve
