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.4 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_LOW,RDNS_NONE,UNPARSEABLE_RELAY autolearn=ham
	autolearn_force=no version=3.4.4
Received: from authenticated user by zero.zsh.org with local 
	id 1kiFJl-000Hka-Of; Thu, 26 Nov 2020 11:20:05 +0000
Authentication-Results: zsh.org;
	iprev=pass (rcpt-expgw.biglobe.ne.jp) smtp.remote-ip=133.208.98.4;
	dmarc=none header.from=kba.biglobe.ne.jp;
	arc=none
Received: from rcpt-expgw.biglobe.ne.jp ([133.208.98.4]:48752)
	by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	id 1kiFJQ-000HVU-DT; Thu, 26 Nov 2020 11:19:46 +0000
Received: from vc-gw.biglobe.ne.jp
	by rcpt-expgw.biglobe.ne.jp (hngd/4514161018) with ESMTP id 0AQBJcuO001751
	for <zsh-workers@zsh.org>; Thu, 26 Nov 2020 20:19:38 +0900
Received: from smtp-gw.biglobe.ne.jp ([192.168.154.160])
	by vc-gw.biglobe.ne.jp (shby/1011270619) with ESMTP id 0AQBJccO026317
	for <zsh-workers@zsh.org>; Thu, 26 Nov 2020 20:19:38 +0900
X-Biglobe-Sender: <takimoto-j@kba.biglobe.ne.jp>
Received: from tamac1.yz.yamagata-u.ac.jp ([133.24.84.20]) by smtp-gw.biglobe.ne.jp
	id U09MC0A89944; Thu, 26 Nov 2020 20:19:38 +0900 (JST)
From: Jun T <takimoto-j@kba.biglobe.ne.jp>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: [PATCHv1] [long] improvements to limit/ulimit API and doc
Date: Thu, 26 Nov 2020 20:19:37 +0900
References: <20201123214942.hi2rx7n3jk25ucmd@chazelas.org>
To: zsh-workers@zsh.org
In-Reply-To: <20201123214942.hi2rx7n3jk25ucmd@chazelas.org>
Message-Id: <37CA6007-8692-4F71-90BF-80C422BE21E3@kba.biglobe.ne.jp>
X-Mailer: Apple Mail (2.3445.104.17)
X-Biglobe-Spnum: 59776
X-Seq: 47634
Archived-At: <https://zsh.org/workers/47634>
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: <zsh-workers.zsh.org>
List-Help: <mailto:sympa@zsh.org?subject=help>
List-Subscribe: <mailto:sympa@zsh.org?subject=subscribe%20zsh-workers>
List-Unsubscribe: <mailto:sympa@zsh.org?subject=unsubscribe%20zsh-workers>
List-Post: <mailto:zsh-workers@zsh.org>
List-Owner: <mailto:zsh-workers-request@zsh.org>
List-Archive: <http://www.zsh.org/sympa/arc/zsh-workers>
Archived-At: <http://www.zsh.org/sympa/arcsearch_id/zsh-workers/2020-11/37CA6007-8692-4F71-90BF-80C422BE21E3%40kba.biglobe.ne.jp>

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



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).