Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Jun T wrote on Thu, Jan 09, 2020 at 19:32:17 +0900:
> 
> > 2020/01/09 6:33, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> > 
> > I don't object to the patch, but we should think about actually using
> > a C preprocessor to parse header files, otherwise we'd just be playing
> > whack-a-mole as OS's use more features of C syntax in their header files.
> 
> Yes, but ...
> 
> When rlimits.awk finds an unknown macro RLIMIT_???, for example
> 
> #define RLIMIT_FOO	8
> 
> then it sets recs[8]="FOO", and this enables the limit builtin to print
> the resource name as "FOO". *If* we need this feature, it would not be
> easy to achieve by using C preprocessor alone.

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:

[[[
static const struct {
    const char *symbol;
    const char *name;
    int type;
    int value;
} rlimits[] = {
#ifdef RLIMIT_CPU
    { "CPU", "cputime", ZLIMTYPE_TIME, RLIMIT_CPU },
#endif
#ifdef RLIMIT_DATA
    { "DATA", "datasize", ZLIMTYPE_MEMORY, RLIMIT_DATA },
#endif
#include "unknown-limits.h"
    { NULL }
};
]]]

where unknown-limits.h is generated (by awk(1)) as:

[[[
#ifdef RLIMIT_FOO
    { "FOO", "FOO", ZLIMTYPE_UNKNOWN, RLIMIT_FOO },
#endif
#ifdef RLIMIT_BAR
    { "BAR", "BAR", ZLIMTYPE_UNKNOWN, RLIMIT_BAR },
#endif
]]]

All limits we know about will be in the first file; any limits we don't know
about will be in the second file

This way the numerical calculations would be done by the preprocessor, and we'd
not be assuming that the integer values of RLIMIT_* macros are sequential and
start from zero.  (Though apparently that assumption happens to be true on
current OS's)

Cheers,

Daniel