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 1kiL0E-0001Wg-Qf; Thu, 26 Nov 2020 17:24:18 +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]:33577) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1kiKzs-0001I1-Qh; Thu, 26 Nov 2020 17:23:57 +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 CCCAEFF80C; Thu, 26 Nov 2020 17:23:55 +0000 (UTC) Date: Thu, 26 Nov 2020 17:23:54 +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: <20201126172354.g5guqrhu3mwrv6ia@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> <20201126135523.7daayb7l543yrmcj@chazelas.org> <05C414E9-A152-40CD-90C3-C74D7FD773A8@kba.biglobe.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05C414E9-A152-40CD-90C3-C74D7FD773A8@kba.biglobe.ne.jp> X-Seq: 47639 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-27 00:22:05 +0900, Jun. T: > > > 2020/11/26 22:55, Stephane Chazelas 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. Yes, looks like it does: if (limit * factor / factor != limit) error(out of range) (where limit is converted from string without overflow check). > > > 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 RLIM_INFINITY. I can't say I know anything about those RLIM_SAVED_XXX. I came across them for the first time today. > Zsh only need to check whether the new limit user wants to set is > within the range of rlim_t. Yes, but how do you determine that range? Should we not also reject 18446744073709551615 as out-of-range on systems where it's RLIM_INFINITY since it's not preventing file sizes to get past 18446744073709551615 for instance. $ bash --posix -c 'ulimit -t 18446744073709551615 && ulimit -t' unlimited yash rejects it: $ yash -c 'ulimit -t 18446744073709551614 && ulimit -t' 18446744073709551614 $ yash -c 'ulimit -t 18446744073709551615 && ulimit -t' ulimit: Numerical result out of range $ yash -c 'ulimit -t 18446744073709551616 && ulimit -t' ulimit: `18446744073709551616' is not a valid integer In any case, while I agree they are valid (though minor) concerns, I won't address them in this round. I can add a "BUGS" entry though. -- Stephane