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 37bdbc66 for ; Sat, 11 Jan 2020 20:16:41 +0000 (UTC) Received: (qmail 12346 invoked by alias); 11 Jan 2020 20:16:34 -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: 45284 Received: (qmail 291 invoked by uid 1010); 11 Jan 2020 20:16:34 -0000 X-Qmail-Scanner-Diagnostics: from wout2-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25684. spamassassin: 3.4.2. Clear:RC:0(64.147.123.25):SA:0(-2.6/5.0):. Processed in 4.868735 secs); 11 Jan 2020 20:16:34 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeihedgudefgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtugfgjggfse htkedttddtreejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggr nhhivghlrdhshhgrhhgrfhdrnhgrmhgvqeenucfkphepjeelrddukedtrdehjedruddule enucfrrghrrghmpehmrghilhhfrhhomhepugdrshesuggrnhhivghlrdhshhgrhhgrfhdr nhgrmhgvnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Date: Sat, 11 Jan 2020 20:15:49 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin Message-ID: <20200111201549.GA1264@tarpaulin.shahaf.local2> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <087AE8B9-35B0-4258-9626-AACA85471A07@kba.biglobe.ne.jp> User-Agent: Mutt/1.10.1 (2018-07-13) Jun T wrote on Fri, Jan 10, 2020 at 19:24:49 +0900: > > > 2020/01/09 22:15, Daniel Shahaf wrote: > > > > Yeah, the C preprocessor can't discover RLIMIT_* macros we don't know about in > > advance, I agree. For that we'd need awk(1) or similar (maybe just «grep -o > > 'RLIMIT_[^ ]*'»). Maybe something along these lines: > > Thanks. > But I've started thinking that we can just use a resource name such as > "unknown8" (instead of "FOO") for unknown resource. Then rlimits.awk can > be removed as you have suggested originally. > > Of cause there is a chance that the tail part of the macro name ("FOO") may > give some hint for users, but it is far from satisfactory anyway. > If users find "unknown8" in the output of the limit builtin, then *hopefully* > they report it to zsh/workers; then we can add it to the list of known > resources easily. I've thought about it and I think I agree. There could be RLIMIT_* macros that aren't valid as arguments to getrlimit(2); assuming otherwise is a bit too hacky, and the alternative — the limit being settable numerically — isn't that bad. We could even add a test that runs «ulimit -a | grep '^-N'» and, if that has any output, prints a warning to stderr (without failing the test run). The part that's not clear to me is how we'd even know that «8» 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? Cheers, Daniel