From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,RDNS_NONE, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.4 Received: from authenticated user by zero.zsh.org with local id 1kiHkS-000MBO-CQ; Thu, 26 Nov 2020 13:55:48 +0000 Authentication-Results: zsh.org; iprev=pass (relay9-d.mail.gandi.net) smtp.remote-ip=217.70.183.199; dmarc=none header.from=chazelas.org; arc=none Received: from relay9-d.mail.gandi.net ([217.70.183.199]:43931) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1kiHk6-000Lwl-67; Thu, 26 Nov 2020 13:55:27 +0000 X-Originating-IP: 94.10.124.211 Received: from chazelas.org (unknown [94.10.124.211]) (Authenticated sender: stephane@chazelas.org) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 50E9AFF80F; Thu, 26 Nov 2020 13:55:24 +0000 (UTC) Date: Thu, 26 Nov 2020 13:55:23 +0000 From: Stephane Chazelas To: Jun T Cc: zsh-workers@zsh.org Subject: Re: [PATCHv1] [long] improvements to limit/ulimit API and doc Message-ID: <20201126135523.7daayb7l543yrmcj@chazelas.org> Mail-Followup-To: Jun T , zsh-workers@zsh.org References: <20201123214942.hi2rx7n3jk25ucmd@chazelas.org> <37CA6007-8692-4F71-90BF-80C422BE21E3@kba.biglobe.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37CA6007-8692-4F71-90BF-80C422BE21E3@kba.biglobe.ne.jp> X-Seq: 47637 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: 2020-11-26 20:19:37 +0900, Jun T: > This is not the problem of the patch, but I noticed limit/ulimit of zsh > has a small problem due to the wrap-around of unsigned integers. > For example, on Linux, either with or without Stephane's patch: > > zsh% ulimit 36028797018963967 && ulimit > 36028797018963967 # = 2**55 - 1 > zsh% ulimit 36028797018963968 && ulimit > 0 > > This is because 36028797018963968 blocks = 2**64, which wrap around to zero. > With the patch we can more easily see: > > zsh% limit filesize 8EiB && limit filesize > filesize 8EiB > zsh% limit filesize 16EiB && limit fillesize > filesize 0B # 16EiB = 2**64 = 0 > > It seems bash is doing some check for the wrap around: > > zsh% bash --posix # block=512B in POSIX mode > bash$ ulimit 36028797018963967 && ulimit > 36028797018963967 > bash$ ulimit 36028797018963968 > bash: ulimit: 36028797018963968: limit out of range But: $ bash --posix -c 'ulimit 18446744073709551617; ulimit' 1 There's also the question of the actual value of RLIM_INFINITY, RLIM_SAVED_MAX, RLIM_SAVED_CUR and whether we can assume RLIM_INFINITY is the maximum possible value. POSIX doesn't seem to give us much guarantee there (https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/sys_resource.h.html) > In B12limit.ztst > > > + if sh -c 'ulimit 2048' > /dev/null 2>&1; then > > Can we assume that there is no hard limit set by the System? > Later in the test we will test up to 1EiB, so maybe it would be safer > to use 'ulimit -f unlimited'? > (All the systems I know do not set any hard limit on filesize > so maybe we need not bother with this). Yes, "make test" is meant for packagers. I'd say it's up to them to update their environment so the tests can run. Now, I'd expect those 1EiB tests would fail on some system whether or not "ulimit -f unlimited" works or not. I haven't found any yet. But if there are any, it's probably better we be told about it (and a failing test is a good way to achieve that). -- Stephane