select call timeout argument
R S Haigh
In SunOS 5, the last argument of select() is declared as struct timeval*,
without const. Does the struct ever actually get modified by the call?
--
Randy Kaelber
R S Haigh (ecl...@sun.leeds.ac.uk) wrote:
> In SunOS 5, the last argument of select() is declared as struct timeval*,
> without const. Does the struct ever actually get modified by the call?
I'm not sure, but I don't think so. Define a constant timeval structure
and pass its address in, and see if you SEGV.
Or, if you're really worried about losing the original values, how painful
can it be to do:
struct timeval t_call, t_original;
.
.
.
t_call.tv_sec = t_original.tv_sec;
t_call.tv_usec = t_original.tv_usec;
and then call select using the &t_call time value?
--
Randy Kaelber: kael...@muohio.edu
DARS Programmer/Analyst, Miami University, Oxford, OH 45056 USA
http://avian.dars.muohio.edu/~randy/
Andrew Gierth
>>>>> "Randy" == Randy Kaelber <ra...@avian.dars.muohio.edu> writes:
> R S Haigh (ecl...@sun.leeds.ac.uk) wrote:
>> In SunOS 5, the last argument of select() is declared as struct timeval*,
>> without const. Does the struct ever actually get modified by the call?
Randy> I'm not sure, but I don't think so.
Almost certainly not, but you should assume that it does.
Relevent quote:
Select() should probably return the time remaining from the original
timeout, if any, by modifying the time value in place. This may be
implemented in future versions of the system. Thus, it is unwise to
assume that the timeout value will be unmodified by the select() call.
(which is in most of the select() manpages I've ever seen, has obviously
been there a long time...)
--
Andrew.
Randy Kaelber
Andrew Gierth (and...@erlenstar.demon.co.uk) wrote:
> Relevent quote:
> Select() should probably return the time remaining from the original
> timeout, if any, by modifying the time value in place. This may be
> implemented in future versions of the system. Thus, it is unwise to
> assume that the timeout value will be unmodified by the select() call.
> (which is in most of the select() manpages I've ever seen, has obviously
> been there a long time...)
Andrew comes through again. :) My man page says nothing about the
modification of the value, one way or the other, which is not surprising,
since I'm running AIX.
In general, If you're passing a pointer to a function that you know
nothing about its internal structure, assume that it's going to mess with
the data it's pointing to, and take appropriate measures. That way,
you'll never get burned.
Marc Slemko
>>>>>> "Randy" == Randy Kaelber <ra...@avian.dars.muohio.edu> writes:
> > R S Haigh (ecl...@sun.leeds.ac.uk) wrote:
> >> In SunOS 5, the last argument of select() is declared as struct timeval*,
> >> without const. Does the struct ever actually get modified by the call?
> Randy> I'm not sure, but I don't think so.
>Almost certainly not, but you should assume that it does.
>Relevent quote:
> Select() should probably return the time remaining from the original
> timeout, if any, by modifying the time value in place. This may be
> implemented in future versions of the system. Thus, it is unwise to
> assume that the timeout value will be unmodified by the select() call.
>(which is in most of the select() manpages I've ever seen, has obviously
>been there a long time...)
And which Linux actually implements. If you assume select() does not
modify the timeout, the program may behave oddly on Linux.
W. Richard Stevens
Posix.1g, which is standardizing select() and poll(), add the "const"
qualifier to the "struct timeval *". So any system that does update
this structure today, will have to change.
Rich Stevens