Re: [UGLY PATCH v2] Support for no-legacy-syscalls archs

[Rich Felker <dalias@libc.org>]

On Tue, May 27, 2014 at 12:39:24AM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2014-05-26 17:54:12 -0400]:
> > On Mon, May 26, 2014 at 11:13:49PM +0200, Szabolcs Nagy wrote:
> > > > +	if (tv) {
> > > > +		ts.tv_sec = tv->tv_sec;
> > > > +		ts.tv_nsec = tv->tv_usec > 999999 ?
> > > > +			999999999 : tv->tv_usec * 1000;
> > > > +	}
> > > > +	return syscall_cp(SYS_pselect6, n, rfds, wfds, efds, tv ? &ts : 0, data);
> > > > +#endif
> > > 
> > > tv_usec may be negative
> > 
> > Then the kernel should generate the EINVAL for us.
> 
> but the multiplication may overflow

Indeed, I missed that.

> > > isnt it better to adjust tv_sec if usec is large?
> > > or fail with EINVAL like in futimensat:
> > 
> > POSIX allows implementation-defined limits on the duration, but now
> > that you say it, what I wrote above is not not a correct
> > implementation of such a limit. I'm not clear on whether we should
> > renormalize into timespec or just reject out-of-range usec values;
> > unlike in some other places where timespec is used, POSIX is missing
> > text on select and pselect regarding how out-of-range timespec and
> > timeval structs should be handled...
> > 
> 
> fwiw the kernel fixes large tv_usec in select:
> 
> ....
>   tv.tv_sec + (tv.tv_usec / USEC_PER_SEC),

Does it handle the overflow here? :)

In any case, doing what the kernel does is probably desirable to
minimize differences between archs.

Rich