From owner-svn-src-all@freebsd.org Sat Oct 22 00:25:21 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CF0DC1C86E for ; Sat, 22 Oct 2016 00:25:21 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CB589832; Sat, 22 Oct 2016 00:25:20 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 7B46910864; Sat, 22 Oct 2016 00:25:19 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id D6E4F439E7; Sat, 22 Oct 2016 02:25:16 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Colin Percival Cc: src-committers@FreeBSD.org, "svn-src-all\@freebsd.org" Subject: Re: cvs commit: src/sys/sys _types.h resource.h References: <200411081805.iA8I5hVK038813@repoman.freebsd.org> <01000157e3ac7982-b19e61c1-1619-44b1-88b5-3080d85e8d6d-000000@email.amazonses.com> <86wph1o8ec.fsf@desk.des.no> <01000157e9447f3f-f307bb1a-7179-48f8-9e6a-fca3cf0de5f5-000000@email.amazonses.com> <86shrpnwzk.fsf@desk.des.no> <01000157e995b411-6ad7331e-440f-4133-ab48-31b56c8384a7-000000@email.amazonses.com> Date: Sat, 22 Oct 2016 02:25:16 +0200 In-Reply-To: <01000157e995b411-6ad7331e-440f-4133-ab48-31b56c8384a7-000000@email.amazonses.com> (Colin Percival's message of "Fri, 21 Oct 2016 23:31:24 +0000") Message-ID: <86oa2dnsb7.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 00:25:21 -0000 Colin Percival writes: > Dag-Erling Sm=C3=B8rgrav writes: > > [...] we might as well change the value of RLIM_INFINITY to (rlim_t)-1 > > to match other OSes, and we can do it without significant breakage. > Should we get a ports experimental run for this? Sure. It might also be a good idea to ask portmgr@ to grep tarballs for rlim_t so we can inspect source code. I just realized that there is a potential for non-benign errors if a userland program compares a number to a limit that happens to be set to RLIM_INFINITY (an older binary will perform a signed comparison, which will return a different result if RLIM_INFINITY is negative when interpreted as a signed number). But userland programs shouldn't be comparing numbers to limits - that's the kernel's job, and the kernel will always be consistent with itself. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no