Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Jun T wrote on Fri, Jan 10, 2020 at 19:24:49 +0900:
> 
> > 2020/01/09 22:15, Daniel Shahaf <d.s@daniel.shahaf.name> 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