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 24686 invoked from network); 20 Mar 2020 19:19:31 -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; 20 Mar 2020 19:19:31 -0000 Received: (qmail 8945 invoked by alias); 20 Mar 2020 19:19:24 -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: 45590 Received: (qmail 12239 invoked by uid 1010); 20 Mar 2020 19:19:24 -0000 X-Qmail-Scanner-Diagnostics: from out5-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25751. spamassassin: 3.4.2. Clear:RC:0(66.111.4.29):SA:0(-2.6/5.0):. Processed in 0.896395 secs); 20 Mar 2020 19:19:24 -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: gggruggvucftvghtrhhoucdtuddrgedugedrudeguddguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfgjfhfogggtsehmtd dtreertdejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggrnhhi vghlrdhshhgrhhgrfhdrnhgrmhgvqeenucfkphepjeelrddukedvrddufedtrddufeehne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugdrshes uggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgv X-ME-Proxy: Date: Fri, 20 Mar 2020 19:18:46 +0000 From: Daniel Shahaf To: Jun T Cc: zsh-workers@zsh.org Subject: Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin Message-ID: <20200320191846.3a4f5682@tarpaulin.shahaf.local2> In-Reply-To: <321F9465-ABF9-465D-9242-7EF9A0EDDBED@kba.biglobe.ne.jp> 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> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/3cQEX9+rs/Vxg0tqNz2rQpj" --MP_/3cQEX9+rs/Vxg0tqNz2rQpj Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Continuing my review: Jun T wrote on Tue, 25 Feb 2020 18:38 +0900: > --- a/Src/Builtins/rlimits.awk > +++ /dev/null > @@ -1,116 +0,0 @@ > -# > -# rlimits.awk: {g,n}awk script to generate rlimits.h > -# > -# NB: On SunOS 4.1.3 - user-functions don't work properly, also \" probl= ems > -# Without 0 + hacks some nawks compare numbers as strings > -# > -BEGIN {limidx =3D 0} > - > -/^[\t ]*(#[\t ]*define[\t _]*RLIMIT_[A-Z_]*[\t ]*[0-9][0-9]*|RLIMIT_[A-Z= _]*,[\t ]*|_*RLIMIT_[A-Z_]*[\t ]*=3D[\t ]*[0-9][0-9]*,[\t ]*)/ { =E2=8B=AE > - if (limnam =3D=3D "RSS") { msg[limnum] =3D "Mresident" } =E2=8B=AE > -END { > - if (limrev["MEMLOCK"] !=3D "") { > - irss =3D limrev["RSS"] > - msg[irss] =3D "Mmemoryuse" > - } =20 Question. I compared the output before and after the patch and I see the following difference: % diff -U0 =3D(zsh-5.7.1 -fc 'limit') =3D(limit) --- /tmp/zshZXxkUD 2020-03-20 18:00:04.239999929 +0000 +++ /tmp/zshxTTscg 2020-03-20 18:00:04.239999929 +0000 @@ -6 +6 @@ -memoryuse unlimited +resident unlimited zsh: exit 1 diff -U0 =3D(zsh-5.7.1 -fc 'limit') =3D(limit) It seems to be caused by the C implementation not having an equivalent of the above piece of code. this difference intentional? > +++ 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 What will happen if two different elements of this array have the same option letter? When I simulate that (by manually changing the =C2=AB'f'=C2=BB to =C2=AB't'= =C2=BB), I get output such as: . % b/Src/zsh -fc 'ulimit -a' -t: cpu time (seconds) unlimited =E2=8B=AE -t: file size (blocks) unlimited . Given this output, people are liable to invoke =C2=ABulimit -t=C2=BB in an attempt to change the file size limit. 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. Therefore, I was wondering if we should have a test for this situation, or possibly a runtime check; see the attached series for example. Sorry for my slow response. Cheers, Daniel --MP_/3cQEX9+rs/Vxg0tqNz2rQpj Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=0001-zsh-rlimits-Make-known_resources-const-in-set_re.patch.txt >From 0f3dc2ee15c6bb1a005728d3d1107cd4da6e0c7f Mon Sep 17 00:00:00 2001 From: Daniel Shahaf Date: Fri, 20 Mar 2020 18:48:28 +0000 Subject: [PATCH 1/2] zsh/rlimits: Make known_resources const in set_resinfo() but not elsewhere. --- Src/Builtins/rlimits.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/Src/Builtins/rlimits.c b/Src/Builtins/rlimits.c index aa9b9dd48..c3c031fff 100644 --- a/Src/Builtins/rlimits.c +++ b/Src/Builtins/rlimits.c @@ -49,8 +49,13 @@ typedef struct resinfo_T { char* descr; /* used by ulimit builtin */ } resinfo_T; -/* table of known resources */ -static const resinfo_T known_resources[] = { +/* table of known resources + * + * Not const since set_resinfo() may change some of the letters to 'N' in case + * of collisions. However, all access should be through the "resinfo" global, + * which exposes this as a const array. + */ +static resinfo_T known_resources[] = { {RLIMIT_CPU, "cputime", ZLIMTYPE_TIME, 1, 't', "cpu time (seconds)"}, {RLIMIT_FSIZE, "filesize", ZLIMTYPE_MEMORY, 512, @@ -175,14 +180,15 @@ static void set_resinfo(void) { int i; + resinfo_T **resinfo_mutable; - resinfo = (const resinfo_T **)zshcalloc(RLIM_NLIMITS*sizeof(resinfo_T *)); + resinfo_mutable = (resinfo_T **)zshcalloc(RLIM_NLIMITS*sizeof(resinfo_T *)); for (i=0; iunit = 1; info->opt = 'N'; info->descr = buf; - resinfo[i] = info; + resinfo_mutable[i] = info; } } + + resinfo = (const resinfo_T **) resinfo_mutable; } /**/ --MP_/3cQEX9+rs/Vxg0tqNz2rQpj Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=0002-zsh-rlimits-Ensure-option-letters-are-unambiguou.patch.txt >From 5ffb506e43cd8dd5ecd1945a93e854f1b735cfd5 Mon Sep 17 00:00:00 2001 From: Daniel Shahaf Date: Fri, 20 Mar 2020 18:49:42 +0000 Subject: [PATCH 2/2] zsh/rlimits: Ensure option letters are unambiguous at runtime. --- Src/Builtins/rlimits.c | 15 +++++++++++++++ Test/B12limit.ztst | 10 ++++++++++ 2 files changed, 25 insertions(+) diff --git a/Src/Builtins/rlimits.c b/Src/Builtins/rlimits.c index c3c031fff..5c260e7db 100644 --- a/Src/Builtins/rlimits.c +++ b/Src/Builtins/rlimits.c @@ -181,11 +181,26 @@ set_resinfo(void) { int i; resinfo_T **resinfo_mutable; + char seen_letters[sizeof(known_resources)/sizeof(resinfo_T) + 1] = {0}; + char *seen_p = seen_letters; resinfo_mutable = (resinfo_T **)zshcalloc(RLIM_NLIMITS*sizeof(resinfo_T *)); for (i=0; i