From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 8932f110 for ; Mon, 13 Jan 2020 11:01:38 +0000 (UTC) Received: (qmail 4396 invoked by alias); 13 Jan 2020 11:01:31 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45294 Received: (qmail 14791 invoked by uid 1010); 13 Jan 2020 11:01:31 -0000 X-Qmail-Scanner-Diagnostics: from rcpt-expgw.biglobe.ne.jp by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25691. spamassassin: 3.4.2. Clear:RC:0(133.208.98.2):SA:0(-2.6/5.0):. Processed in 3.930547 secs); 13 Jan 2020 11:01:31 -0000 X-Envelope-From: takimoto-j@kba.biglobe.ne.jp X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at spf01.biglobe.ne.jp designates 133.208.98.2 as permitted sender) X-Biglobe-Sender: From: Jun T Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin Date: Mon, 13 Jan 2020 20:00:52 +0900 References: <82F8CDE0-C95C-4D31-ABFC-EBB3C97799F3@kba.biglobe.ne.jp> <1B509B1C-A670-482F-9D88-2145E15D03A1@kba.biglobe.ne.jp> <20200109131553.hqetnd45sc43z6xb@tarpaulin.shahaf.local2> <087AE8B9-35B0-4258-9626-AACA85471A07@kba.biglobe.ne.jp> <20200111201549.GA1264@tarpaulin.shahaf.local2> To: zsh-workers@zsh.org In-Reply-To: <20200111201549.GA1264@tarpaulin.shahaf.local2> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-Biglobe-Spnum: 55991 > 2020/01/12 5:15, Daniel Shahaf wrote: >=20 > The part that's not clear to me is how we'd even know that =C2=AB8=C2=BB= is a valid value for > the first actual argument to getrlimit(). Currently, the code assumes = that the > values of RLIMIT_* macros are consecutive small integers, but that is = not guaranteed > by any standard, is it? There is no guarantee, but current version of ulimit builtin accepts any = number for -N (and output error). limit builtin accepts only the resource name, and maybe we accept "unknonw8" only for getrlimit() but not for = setrlimit()?