From owner-svn-src-head@FreeBSD.ORG Fri Feb 13 17:01:19 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8195290A for ; Fri, 13 Feb 2015 17:01:19 +0000 (UTC) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3642DB51 for ; Fri, 13 Feb 2015 17:01:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423846871; bh=8VEP4ncQ0nnFdBznWxRUSZKXGWQSf4QHRoWcUOezw6Q=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=BOJhJ/TUfpSDroUIDhpgp0cjGBqPOMtLSVYvXoTZCUOHjN8zZe2VlxcsB6zN+4pLG8nkbu46hpAR3uAhwyjf10Kxfq5rIzAy3F+yY8O7pq78uBklSZpP5tf+JYZbo4e9kk19gVg7oMeYjud+kU6Y7N6yQLjX9NtZydWYCcdLyG9iRPsggYJeOs4IwPUGzIU6IP8h5yi21YbzZkYgw9qrvgXzJOI8Y9ksbvrIhqDFJYchcimYwjvoCxbk5aKvQW6U2vT6kHeyXyXg5l9EOHH+U4TSAK1qtCEaTRdivuhVBiJdj4MFG/+DnjRzrEYNCQDGhipEFb9SC31OX94IKFFNzg== Received: from [66.196.81.170] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 13 Feb 2015 17:01:11 -0000 Received: from [98.139.213.12] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 13 Feb 2015 17:01:11 -0000 Received: from [127.0.0.1] by smtp112.mail.bf1.yahoo.com with NNFMP; 13 Feb 2015 17:01:11 -0000 X-Yahoo-Newman-Id: 774838.3979.bm@smtp112.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: N3v7OnAVM1kPKbuydZglnKZqsh4._opaXsqJtfmcfHyTd98 .g9gYSOJQrF7KMi1cr.j8C.MESMM8IcMpvqJubHvbU9UGNwxVqEb7Nm5n3X1 oMcLThajWvZyrPyB8tLJ8sAfnps58nHaWeBSTYA6zgUYXgRL7O4wBdLLULhn PGbQNs29K5Am2L_N_.bPdOlY1ExFT2ED6LLiDiDCW1m6H_wkiQr4MJyIQANZ Nfml0QQ59ifR3sYq_Na.0W0sR_bpMjCaVjA5.58DScPsFT4b5Qs2P_M3guW8 J6gQSyZJO6HvfnXfB3HK678mv3wSKrMEH2EIrxEwSruNPlhmtzIRydI9cNiU d9jJXd7MeEF2jPP9KryLQdhy5uQHGaqs1rExShY0zZWC0gclZu5Bg4a1_9Uw _UGrpp2JxgVx_Wh_DmjL1QTgR9Otch5.ZNbbjDqRUicPTTteG03uDJvP2Nfj .6M6n_DKZ0vfgpPcygGaNDKle4wVB54w5JgbOWI1KlYr4BqEPLZRADOTbfYK ZxX5tkOwmSBchTdf9FwILKf_VMnUb.Q-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <54DE2DE3.7050004@FreeBSD.org> Date: Fri, 13 Feb 2015 12:01:23 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bruce Evans Subject: Re: svn commit: r278634 - head/lib/libc/gen References: <201502122107.t1CL7gaO004041@svn.freebsd.org> <54DD2A87.2050008@FreeBSD.org> <9A683D99-C1E9-4736-982C-69F583D3A40D@FreeBSD.org> <20150213172738.C1007@besplex.bde.org> <54DDABF2.9000201@freebsd.org> <54DDAEF6.3060900@freebsd.org> <20150214005543.X2210@besplex.bde.org> <54DE1FC9.4000503@FreeBSD.org> <20150214032839.E3221@besplex.bde.org> In-Reply-To: <20150214032839.E3221@besplex.bde.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Andrey Chernov X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 17:01:19 -0000 On 02/13/15 11:46, Bruce Evans wrote: > On Fri, 13 Feb 2015, Pedro Giffuni wrote: > >> On 02/13/15 09:29, Bruce Evans wrote: >>> On Fri, 13 Feb 2015, Andrey Chernov wrote: >>> >>>> We even don't need to check arg excepting for < 0, because what is >>>> needed is rlimt_t and not arg. So this version will be better: >>>> >>>> rlimt_t targ; >>>> >>>> if (arg < 0) { >>>> errno = EINVAL; >>>> return (-1); >>>> } >>> >>> >>> This is reasonable, but not encouraged by the API or compatible with >>> what setrlimit() does with negative args. (setrlimit() still uses >>> my hack from 1994, of converting negative args to RLIM_INFINITY. In >>> 4.4BSD, it doesn't even check for negative args, and mostly stores >>> them unchanged; then undefined behaviour tends to occur when the >>> stored values are used without further checking.) >> >> Actually I think the above check would be OK according to POSIX: >> ... >> >> The /ulimit/() function shall fail and the limit shall be unchanged if: >> >> [EINVAL] >> The /cmd/ argument is not valid. >> ... > > I already partly explained that this is (part of) why POSIX discourages > returning EINVAL for the /data/ argument. EINVAL is for the /cmd/ > argument. No errno is specified for the /data/ argument. Instead, > the implementation is implicitly encourage to (if the requested value > is unrepresentable) invent some representable value and return the > result of setting it. We still often get EPERM if our invented value > cannot be set due to EPERM. Rounding makes EPERM even more likely > than ususal. E.g., if we start with RLIM_INFINITY and get and set it > using some implementations of this function, then rounding reduces > the hard rlimit. Then if a slightly different implementation tries > to increase the hard rlimit hack to RLIM_INFINITY, then this fails > with EPERM (except for root). Some preliminary attempts to fix the > warning would have caused this EPERM error for almost all error > cases, since non-error cases rounded down but error cases attempted > to raise to RLIM_INFINITY. > Oops.. OK, I am pretty bad reading specifications. >> ... >>> An incomplete fix with handling of negative values restored is >>> something >>> like: >>> >>> intmax_t targ; >>> >>> targ = arg; >>> if (targ > RLIM_INFINITY / 512) >>> targ = RLIM_INFINITY / 512; >>> limit.rlim_max = limit.rlim_cur = targ * 512 >>> >>> This is still incomplete. The comparison is still obviously >>> tautologous >>> when intmax_t == rlim_t (the amd64 case). If intmax_t is larger than >>> long (the i386 case) or even rlim_t (the notyet case), then it is >>> slightly >>> less obviously tautologous. This can be fixed by sprinkling volatiles, >>> e.g. for targ. >> >> I am passing this (with the check for negative values and __intmax_t) >> through the tinderbox. >> FWIW, I had something else that managed to compile but is *very* >> ugly and can cause an effect similar to tear gas on sensitive eyes ;). > > I also forgot to include for the declaration of intmax_t. > Use of double underscores in applications is also bad for the eyes. > OK. The patch passes tinderbox. The only missing thing is what to do about arg (iff it has to be adjusted). Pedro.