[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140526223924.GK12324@port70.net>
Date: Tue, 27 May 2014 00:39:24 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [UGLY PATCH v2] Support for no-legacy-syscalls archs
* 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
> > 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),
(tv.tv_usec % USEC_PER_SEC) * NSEC_PER_USEC))
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.
