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,RDNS_NONE,UNPARSEABLE_RELAY autolearn=no
	autolearn_force=no version=3.4.4
Received: from authenticated user by zero.zsh.org with local 
	id 1kikds-000O2l-EJ; Fri, 27 Nov 2020 20:46:56 +0000
Authentication-Results: zsh.org;
	iprev=pass (relay8-d.mail.gandi.net) smtp.remote-ip=217.70.183.201;
	dmarc=none header.from=chazelas.org;
	arc=none
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:50403)
	by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	id 1kikdZ-000No8-MF; Fri, 27 Nov 2020 20:46:38 +0000
X-Originating-IP: 94.10.124.211
Received: from chazelas.org (unknown [94.10.124.211])
	(Authenticated sender: stephane@chazelas.org)
	by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id C44531BF209;
	Fri, 27 Nov 2020 20:46:35 +0000 (UTC)
Date: Fri, 27 Nov 2020 20:46:35 +0000
From: Stephane Chazelas <stephane@chazelas.org>
To: "Jun. T" <takimoto-j@kba.biglobe.ne.jp>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCHv1] [long] improvements to limit/ulimit API and doc
Message-ID: <20201127204635.glhkhy2ndituvffo@chazelas.org>
Mail-Followup-To: "Jun. T" <takimoto-j@kba.biglobe.ne.jp>,
	zsh-workers@zsh.org
References: <20201123214942.hi2rx7n3jk25ucmd@chazelas.org>
 <37CA6007-8692-4F71-90BF-80C422BE21E3@kba.biglobe.ne.jp>
 <20201126135523.7daayb7l543yrmcj@chazelas.org>
 <05C414E9-A152-40CD-90C3-C74D7FD773A8@kba.biglobe.ne.jp>
 <20201126172354.g5guqrhu3mwrv6ia@chazelas.org>
 <FF7E5A4B-E00F-4160-AFBD-45783C0BAF7B@kba.biglobe.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <FF7E5A4B-E00F-4160-AFBD-45783C0BAF7B@kba.biglobe.ne.jp>
X-Seq: 47672
Archived-At: <https://zsh.org/workers/47672>
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/20201127204635.glhkhy2ndituvffo%40chazelas.org>

2020-11-28 03:24:04 +0900, Jun. T:
[...]
> I guess you mean we should reject RLIM_INFINITY, and yes I agree with it.
> How about the patch below (to your v2)?
[...]

It should probably reject RLIM_SAVED_MAX and RLIM_SAVED_CUR like
yash does as well.

[...]
> +	if ((tmp = ret*unit) < ret) {
> +	    *err = "limit out of range";
> +	    return 0;
[...]

I don't think that's a valid check. It would still accept 17EiB
for instance which is the same as 1EiB with rlimt_t === uint64
and greater than 17.

The problem may be better addressed by reviewing overflow
handling everywhere in the code, probably factorising all code
that does parses decimal integer representations, maybe using
strtoll(), etc. I remember seeing a few bug reports here about
overflow handling in arithmetic evaluation, I'm not sure they've
all been fixed. And I'd be surprised if there aren't other
places where this kind of string to number manual handling
without overflow check is done. 

It probably calls for somebody having a thorough look at the
code, and come up with a plan to address the issue globally,
which goes beyond the scope of this rlimit improvement, I say.

-- 
Stephane