zsh-workers
 help / color / Atom feed
* [PATCH] find RLIM_NLIMITS correctly on Cygwin
@ 2020-01-08 10:39 Jun T
  2020-01-08 21:33 ` Daniel Shahaf
  0 siblings, 1 reply; 10+ messages in thread
From: Jun T @ 2020-01-08 10:39 UTC (permalink / raw)
  To: zsh-workers

On Cygwin, <sys/resource.h> has lines like:

#define RLIMIT_NLIMITS  7       /* upper bound of RLIMIT_* defines */
#define RLIM_NLIMITS    RLIMIT_NLIMITS

but rlimits.awk fails to find the value of RLIM_NLIMITS
(and sets ZSH_NLIMITS to zero).



diff --git a/Src/Builtins/rlimits.awk b/Src/Builtins/rlimits.awk
index e9c576c66..4cf960314 100644
--- a/Src/Builtins/rlimits.awk
+++ b/Src/Builtins/rlimits.awk
@@ -79,6 +79,12 @@ BEGIN {limidx = 0}
     split(limtail, tmp)
     nlimits = tmp[2]
 }
+# for Cygwin
+/^[\t ]*#[\t ]*define[\t ]*RLIM_NLIMITS[\t ]*RLIMIT_NLIMITS/ {
+    if (!nlimits && limrev["NLIMITS"]) {
+      nlimits = limrev["NLIMITS"]
+    }
+}
 
 END {
     if (limrev["MEMLOCK"] != "") {



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin
  2020-01-08 10:39 [PATCH] find RLIM_NLIMITS correctly on Cygwin Jun T
@ 2020-01-08 21:33 ` Daniel Shahaf
  2020-01-09 10:32   ` Jun T
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Shahaf @ 2020-01-08 21:33 UTC (permalink / raw)
  To: Jun T, zsh-workers

Jun T wrote on Wed, 08 Jan 2020 10:39 +00:00:
> On Cygwin, <sys/resource.h> has lines like:
> 
> #define RLIMIT_NLIMITS  7       /* upper bound of RLIMIT_* defines */
> #define RLIM_NLIMITS    RLIMIT_NLIMITS
> 
> but rlimits.awk fails to find the value of RLIM_NLIMITS
> (and sets ZSH_NLIMITS to zero).

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.

Actually, looking at the generated $builddir/Src/Builtins/rlimits.h file,
couldn't we move the entire thing into Src/Builtins/rlimits.c?  Instead of
«recs[lim]» we could have «recs(lim)», using the following function:

static inline const char *recs(int lim)
{
    if (lim == RLIMIT_AIO_MEM) return "aiomemorylocked";
    if (lim == RLIMIT_AIO_OPS) return "aiooperations";
    ⋮
}

And then another such function for «limtype», replace the «for(i = 0; i <
ZSH_NLIMITS; i++)» loops by looping on all RLIMIT_* macros that are
#define'd by the OS, and good riddance to the awk script…

Cheers,

Daniel

> 
> diff --git a/Src/Builtins/rlimits.awk b/Src/Builtins/rlimits.awk
> index e9c576c66..4cf960314 100644
> --- a/Src/Builtins/rlimits.awk
> +++ b/Src/Builtins/rlimits.awk
> @@ -79,6 +79,12 @@ BEGIN {limidx = 0}
>      split(limtail, tmp)
>      nlimits = tmp[2]
>  }
> +# for Cygwin
> +/^[\t ]*#[\t ]*define[\t ]*RLIM_NLIMITS[\t ]*RLIMIT_NLIMITS/ {
> +    if (!nlimits && limrev["NLIMITS"]) {
> +      nlimits = limrev["NLIMITS"]
> +    }
> +}
>  
>  END {
>      if (limrev["MEMLOCK"] != "") {
> 
> 
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin
  2020-01-08 21:33 ` Daniel Shahaf
@ 2020-01-09 10:32   ` Jun T
  2020-01-09 13:15     ` Daniel Shahaf
  0 siblings, 1 reply; 10+ messages in thread
From: Jun T @ 2020-01-09 10:32 UTC (permalink / raw)
  To: zsh-workers


> 2020/01/09 6:33, Daniel Shahaf <d.s@daniel.shahaf.name> 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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin
  2020-01-09 10:32   ` Jun T
@ 2020-01-09 13:15     ` Daniel Shahaf
  2020-01-10 10:24       ` Jun T
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Shahaf @ 2020-01-09 13:15 UTC (permalink / raw)
  To: zsh-workers

Jun T wrote on Thu, Jan 09, 2020 at 19:32:17 +0900:
> 
> > 2020/01/09 6:33, Daniel Shahaf <d.s@daniel.shahaf.name> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin
  2020-01-09 13:15     ` Daniel Shahaf
@ 2020-01-10 10:24       ` Jun T
  2020-01-11 20:15         ` Daniel Shahaf
  0 siblings, 1 reply; 10+ messages in thread
From: Jun T @ 2020-01-10 10:24 UTC (permalink / raw)
  To: zsh-workers


> 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.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin
  2020-01-10 10:24       ` Jun T
@ 2020-01-11 20:15         ` Daniel Shahaf
  2020-01-13 11:00           ` Jun T
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Shahaf @ 2020-01-11 20:15 UTC (permalink / raw)
  To: zsh-workers

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin
  2020-01-11 20:15         ` Daniel Shahaf
@ 2020-01-13 11:00           ` Jun T
  2020-01-13 16:42             ` Daniel Shahaf
  0 siblings, 1 reply; 10+ messages in thread
From: Jun T @ 2020-01-13 11:00 UTC (permalink / raw)
  To: zsh-workers



> 2020/01/12 5:15, Daniel Shahaf <d.s@daniel.shahaf.name> 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()?


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin
  2020-01-13 11:00           ` Jun T
@ 2020-01-13 16:42             ` Daniel Shahaf
  2020-01-14  4:44               ` Jun T
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Shahaf @ 2020-01-13 16:42 UTC (permalink / raw)
  To: zsh-workers

Jun T wrote on Mon, 13 Jan 2020 11:00 +00:00:
> 
> 
> > 2020/01/12 5:15, Daniel Shahaf <d.s@daniel.shahaf.name> 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?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin
  2020-01-13 16:42             ` Daniel Shahaf
@ 2020-01-14  4:44               ` Jun T
  2020-01-14 16:25                 ` Daniel Shahaf
  0 siblings, 1 reply; 10+ messages in thread
From: Jun T @ 2020-01-14  4:44 UTC (permalink / raw)
  To: zsh-workers


> 2020/01/14 1:42, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 
> Jun T wrote on Mon, 13 Jan 2020 11:00 +00:00:
>> 
>>> 2020/01/12 5:15, Daniel Shahaf <d.s@daniel.shahaf.name> 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 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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] find RLIM_NLIMITS correctly on Cygwin
  2020-01-14  4:44               ` Jun T
@ 2020-01-14 16:25                 ` Daniel Shahaf
  0 siblings, 0 replies; 10+ messages in thread
From: Daniel Shahaf @ 2020-01-14 16:25 UTC (permalink / raw)
  To: zsh-workers

Jun T wrote on Tue, 14 Jan 2020 04:44 +00:00:
> 
> > 2020/01/14 1:42, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > 
> > Jun T wrote on Mon, 13 Jan 2020 11:00 +00:00:
> >> 
> >>> 2020/01/12 5:15, Daniel Shahaf <d.s@daniel.shahaf.name> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, back to index

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-08 10:39 [PATCH] find RLIM_NLIMITS correctly on Cygwin Jun T
2020-01-08 21:33 ` Daniel Shahaf
2020-01-09 10:32   ` Jun T
2020-01-09 13:15     ` Daniel Shahaf
2020-01-10 10:24       ` Jun T
2020-01-11 20:15         ` Daniel Shahaf
2020-01-13 11:00           ` Jun T
2020-01-13 16:42             ` Daniel Shahaf
2020-01-14  4:44               ` Jun T
2020-01-14 16:25                 ` Daniel Shahaf

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git