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 \" problems > -# Without 0 + hacks some nawks compare numbers as strings > -# > -BEGIN {limidx = 0} > - > -/^[\t ]*(#[\t ]*define[\t _]*RLIMIT_[A-Z_]*[\t ]*[0-9][0-9]*|RLIMIT_[A-Z_]*,[\t ]*|_*RLIMIT_[A-Z_]*[\t ]*=[\t ]*[0-9][0-9]*,[\t ]*)/ { ⋮ > - if (limnam == "RSS") { msg[limnum] = "Mresident" } ⋮ > -END { > - if (limrev["MEMLOCK"] != "") { > - irss = limrev["RSS"] > - msg[irss] = "Mmemoryuse" > - } Question. I compared the output before and after the patch and I see the following difference: % diff -U0 =(zsh-5.7.1 -fc 'limit') =(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 =(zsh-5.7.1 -fc 'limit') =(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[] = { > + {RLIMIT_CPU, "cputime", ZLIMTYPE_TIME, 1, > + 't', "cpu time (seconds)"}, > + {RLIMIT_FSIZE, "filesize", ZLIMTYPE_MEMORY, 512, > + 'f', "file size (blocks)"}, > ⋮ What will happen if two different elements of this array have the same option letter? When I simulate that (by manually changing the «'f'» to «'t'»), I get output such as: . % b/Src/zsh -fc 'ulimit -a' -t: cpu time (seconds) unlimited ⋮ -t: file size (blocks) unlimited . Given this output, people are liable to invoke «ulimit -t» 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