From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5166 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [UGLY PATCH v2] Support for no-legacy-syscalls archs Date: Tue, 27 May 2014 00:39:24 +0200 Message-ID: <20140526223924.GK12324@port70.net> References: <20140525054237.GA18085@brightrain.aerifal.cx> <20140526184036.GZ507@brightrain.aerifal.cx> <20140526211349.GJ12324@port70.net> <20140526215412.GA507@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1401143985 14855 80.91.229.3 (26 May 2014 22:39:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 May 2014 22:39:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5171-gllmg-musl=m.gmane.org@lists.openwall.com Tue May 27 00:39:38 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Wp3YP-0006Rb-FY for gllmg-musl@plane.gmane.org; Tue, 27 May 2014 00:39:37 +0200 Original-Received: (qmail 11466 invoked by uid 550); 26 May 2014 22:39:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11458 invoked from network); 26 May 2014 22:39:36 -0000 Content-Disposition: inline In-Reply-To: <20140526215412.GA507@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:5166 Archived-At: * Rich Felker [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))