A problem with the select(2) interface

[MQ]

2007/5/14, Dag-Erling Smørgrav <des at des.no>:
>
> MQ <antinvidia at gmail.com> writes:
> > I'm writing a network application these days, for compatibility, I
> choose
> > the select(2) interface to do event polling. When using it, I'm curious
> > about the fact that the type of the final parameter is `struct timeval
> *'. I
> > skimmed through the codes in /sys/kern/sys_generic.c, there is nothing
> > written to this address. So, I think if we can use `const struct timeval
> *'
> > instead? This type can inform the users explicitly that we do NOT modify
> the
> > timeval struct. But I'm not sure if this modification will conflict with
> the
> > POSIX standard. Will you please tell me your considerations? Any
> suggestions
> > will be appreciated.
>
> According to POSIX, the struct timeval may be updated to reflect the
> amount of time left if select() returns early (so you can call select()
> again with the same struct timeval and hit your original deadline).  In
> reality, there is so much old code around that depends on it *not* being
> updated that this has never been implemented.
>
> This is often mentioned as an example of why blindly implementing a
> standard is not a good idea.
>
> DES
> --
> Dag-Erling Smørgrav - des at des.no
>

I'm very sorry that yesterday I replied to des only by mistake. For
completeness, the mail is here.

I don't think it makes to much difference if we add a `const' qualifier to
the type.
There are 4 types of conditions when porting the applications which use
select(2):
1. from FreeBSD to an OS that doesn't modify this timeval struct
2. from FreeBSD to an OS that DO modify this timeval struct
3. from an OS that doesn't update this struct to FreeBSD
4. from an OS that update this struct to FreeBSD

In circumstance 2 and circumstance 4, the programmer should always concern
that the difference between the source platform and destination platform. So
add a `const' qualifier does not affect the original codes too much.
In circumstance 3, we can directly accept the codes. The addtional `const'
qualifier can be simply ignored. Because the cast from a `type *' to `const
type *' is acceptable.
In circumstance 1, adding a `const' qualifier in our implementation may make
things a bit different. The addtional `const' allows a pointer variable of
type `const struct timeval *' to be passed to select(2). If someone have
done something like that, his code would be warned by the compiler under
other platforms in which select(2) accepts only `struct timeval *'.

After all, I don't think this is a real problem with the first condition. So
is there any other reasons that we should not add the qualifier? Actually,
what I was anxious about is that there is some rules that ask the committers
to follow the standards stringently. If adjusting the type is impossible,
shall we add some comments in the man page to reflect that we do not write
to the address?