From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 Received: (qmail 31012 invoked from network); 23 Mar 2020 05:41:44 -0000 Received-SPF: pass (primenet.com.au: domain of zsh.org designates 203.24.36.2 as permitted sender) receiver=inbox.vuxu.org; client-ip=203.24.36.2 envelope-from= Received: from unknown (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTP; 23 Mar 2020 05:41:44 -0000 Received: (qmail 18912 invoked by alias); 23 Mar 2020 05:41:37 -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: 45606 Received: (qmail 7282 invoked by uid 1010); 23 Mar 2020 05:41:37 -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.2/25758. spamassassin: 3.4.2. Clear:RC:0(133.208.98.2):SA:0(-2.6/5.0):. Processed in 1.63822 secs); 23 Mar 2020 05:41:37 -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, 23 Mar 2020 14:41:02 +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> <3340070A-53DD-40F0-8363-A8C7D84702D3@kba.biglobe.ne.jp> <374cecf6-45d5-4688-861f-cc52017dbcea@www.fastmail.com> <321F9465-ABF9-465D-9242-7EF9A0EDDBED@kba.biglobe.ne.jp> <20200320191846.3a4f5682@tarpaulin.shahaf.local2> To: zsh-workers@zsh.org In-Reply-To: <20200320191846.3a4f5682@tarpaulin.shahaf.local2> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-Biglobe-Spnum: 51788 reply 2/2 to workers/45590=E2=81=A9 > 2020/03/21 4:18, Daniel Shahaf wrote: >=20 > Jun T wrote on Tue, 25 Feb 2020 18:38 +0900: >=20 >> +++ b/Src/Builtins/rlimits.c >> @@ -53,11 +40,214 @@ enum { >> +/* table of known resources */ >> +static resinfo_t known_resources[] =3D { >> + {RLIMIT_CPU, "cputime", ZLIMTYPE_TIME, 1, >> + 't', "cpu time (seconds)"}, >> + {RLIMIT_FSIZE, "filesize", ZLIMTYPE_MEMORY, 512, >> + 'f', "file size (blocks)"}, >> =E2=8B=AE >=20 > What will happen if two different elements of this array have the same > option letter? (snip) > Currently, each of the letters [mrvx] is used by two different = elements. > I haven't checked whether both elements of any of these pairs can be > present on a single system, but in any case, more collisions may be > added in the future. I believe *currently* there is no conflict. I was just hoping that if someone add a new resource (with a new option letter) in the future they will be sure to test it (by running 'ulimit-a') and notice the conflict if any. But I agree this is too optimistic. > Therefore, I was wondering if we should have a test for this = situation, > or possibly a runtime check; see the attached series for example. Thank you for the patches. Personally I feel only adding a test (B12limit.zsh) is enough for now, = but have no objection to adding a runtime check in rlimits.c. Do we really need resinfo_mutable? Changes to the data in known_resouces is done via the pointer = current_letter: char *current_letter =3D &known_resources[i].opt; Constness of resinfo does not interfere with this. # and the data for unknown resource (if any) is setup using the pointer # resinfo_T *info =3D (resinfo_T *)zshcalloc(sizeof(resinfo_T)); # and the assignment "resinfo[i] =3D info" does not conflict with the # constness of resinfo. Using resinfo instead of resinfo_mutable gives no warning for me (gcc on Linux and clang on macOS).