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 1kiJ6T-000OS1-7W; Thu, 26 Nov 2020 15:22:37 +0000
Authentication-Results: zsh.org;
	iprev=pass (rcpt-expgw.biglobe.ne.jp) smtp.remote-ip=133.208.98.1;
	dmarc=none header.from=kba.biglobe.ne.jp;
	arc=none
Received: from rcpt-expgw.biglobe.ne.jp ([133.208.98.1]:41774)
	by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	id 1kiJ63-000ODI-R5; Thu, 26 Nov 2020 15:22:13 +0000
Received: from vc-gw.biglobe.ne.jp
	by rcpt-expgw.biglobe.ne.jp (hngd/4514161018) with ESMTP id 0AQFM5U6005679
	for <zsh-workers@zsh.org>; Fri, 27 Nov 2020 00:22:05 +0900
Received: from smtp-gw.biglobe.ne.jp ([192.168.154.158])
	by vc-gw.biglobe.ne.jp (shby/1011270619) with ESMTP id 0AQFM5CL026311
	for <zsh-workers@zsh.org>; Fri, 27 Nov 2020 00:22:05 +0900
X-Biglobe-Sender: <takimoto-j@kba.biglobe.ne.jp>
Received: from [192.168.0.23] ([14.9.102.64]) by smtp-gw.biglobe.ne.jp
	id A0HIC0A89942; Fri, 27 Nov 2020 00:22:05 +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: Fri, 27 Nov 2020 00:22:05 +0900
References: <20201123214942.hi2rx7n3jk25ucmd@chazelas.org>
 <37CA6007-8692-4F71-90BF-80C422BE21E3@kba.biglobe.ne.jp>
 <20201126135523.7daayb7l543yrmcj@chazelas.org>
To: zsh-workers@zsh.org
In-Reply-To: <20201126135523.7daayb7l543yrmcj@chazelas.org>
Message-Id: <05C414E9-A152-40CD-90C3-C74D7FD773A8@kba.biglobe.ne.jp>
X-Mailer: Apple Mail (2.3445.104.17)
X-Biglobe-Spnum: 21560
X-Seq: 47638
Archived-At: <https://zsh.org/workers/47638>
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/05C414E9-A152-40CD-90C3-C74D7FD773A8%40kba.biglobe.ne.jp>


> 2020/11/26 22:55, Stephane Chazelas <stephane@chazelas.org> wrote:
> 
> But:
> 
> $ bash --posix -c 'ulimit 18446744073709551617;  ulimit'
> 1

I think this is a bug of bash.
It seems bash checks the wrap around only for the calculation of
bytes = 512*blocks, and does not check if the number of blocks
is already wrapped around.

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

I guess zsh need not care about these things.

# I must say I don't know what it means if RLIM_SAVED_XXX is not
# equal to RLIMI_INFINITY.

Zsh only need to check whether the new limit user wants to set is
within the range of rlim_t.

If it is not, then zsh should warn about it instead of passing the
wrap-around value to setrlimit(2).

If it is, then just pass it to setrlimit(2) (need not check whether
it is smaller than RLIM_INFINITY or not).
If setrlimit() returns error, then report it to the user.

Jun