Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

Jun T wrote on Tue, 14 Jan 2020 04:44 +00:00:
> 
> > 2020/01/14 1:42, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> > 
> > Jun T wrote on Mon, 13 Jan 2020 11:00 +00:00:
> >> 
> >>> 2020/01/12 5:15, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> >>> 
> >>> 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?
> >> 
> >> There is no guarantee, but current version of ulimit builtin accepts any number
> >> for -N (and output error). limit builtin accepts only the resource name,
> >> and maybe we accept "unknonw8" only for getrlimit() but not for setrlimit()?
> > 
> > Sorry, I don't follow.  Why shouldn't we accept "unknown8" in the limit-setting syntaxes?
> 
> Sorry for my unclear English.
> 
> Why do you think that knowing "8" is a valid resource number is important?

I don't think that.  I was asking a rhetorical question, the implication
being that we _should_ allow setting limits by number even when that
number was not determined to be known-good at build time.

> I think we can just call {get, set}rlimit() with any resource number,
> but if you think it better to avoid using questionable resource
> number, then we can avoid calling setrlimit() that may actually change
> the limit of "unknown" resource. But ulimit -N 8 can change the limit
> anyway, so I think we can call {get, set}rlimit() with any resource
> number specified by the user.

+1, agreed.

Cheers,

Daniel