[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140526224655.GB507@brightrain.aerifal.cx>
Date: Mon, 26 May 2014 18:46:55 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [UGLY PATCH v2] Support for no-legacy-syscalls archs
On Tue, May 27, 2014 at 12:39:24AM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
