zsh-workers
 help / color / mirror / code / Atom feed
From: Stephane Chazelas <stephane@chazelas.org>
To: Jun T <takimoto-j@kba.biglobe.ne.jp>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCHv1] [long] improvements to limit/ulimit API and doc
Date: Thu, 26 Nov 2020 13:55:23 +0000	[thread overview]
Message-ID: <20201126135523.7daayb7l543yrmcj@chazelas.org> (raw)
In-Reply-To: <37CA6007-8692-4F71-90BF-80C422BE21E3@kba.biglobe.ne.jp>

2020-11-26 20:19:37 +0900, Jun T:
> This is not the problem of the patch, but I noticed limit/ulimit of zsh
> has a small problem due to the wrap-around of unsigned integers.
> For example, on Linux, either with or without Stephane's patch:
> 
> zsh% ulimit 36028797018963967 && ulimit
> 36028797018963967                          # = 2**55 - 1
> zsh% ulimit 36028797018963968 && ulimit
> 0
> 
> This is because 36028797018963968 blocks = 2**64, which wrap around to zero.
> With the patch we can more easily see:
> 
> zsh% limit filesize 8EiB && limit filesize
> filesize        8EiB
> zsh% limit filesize 16EiB && limit fillesize
> filesize        0B           # 16EiB = 2**64 = 0
> 
> It seems bash is doing some check for the wrap around:
> 
> zsh% bash --posix            # block=512B in POSIX mode
> bash$ ulimit 36028797018963967 && ulimit
> 36028797018963967
> bash$ ulimit 36028797018963968
> bash: ulimit: 36028797018963968: limit out of range

But:

$ bash --posix -c 'ulimit 18446744073709551617;  ulimit'
1

There's also the question of the actual value of RLIM_INFINITY,
RLIM_SAVED_MAX, RLIM_SAVED_CUR and whether we can assume
RLIM_INFINITY is the maximum possible value.

POSIX doesn't seem to give us much guarantee there
(https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/sys_resource.h.html)


> In B12limit.ztst
> 
> > +  if sh -c 'ulimit 2048' > /dev/null 2>&1; then
> 
> Can we assume that there is no hard limit set by the System?
> Later in the test we will test up to 1EiB, so maybe it would be safer
> to use 'ulimit -f unlimited'?
> (All the systems I know do not set any hard limit on filesize
> so maybe we need not bother with this).

Yes, "make test" is meant for packagers. I'd say it's up to them
to update their environment so the tests can run.

Now, I'd expect those 1EiB tests would fail on some system
whether or not "ulimit -f unlimited" works or not. I haven't
found any yet. But if there are any, it's probably better we be
told about it (and a failing test is a good way to achieve
that).

-- 
Stephane



  reply	other threads:[~2020-11-26 13:55 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-23 21:49 Stephane Chazelas
2020-11-25  0:35 ` Daniel Shahaf
2020-11-25  6:44   ` Stephane Chazelas
2020-11-27 17:16     ` Daniel Shahaf
2020-11-26  6:57   ` [PATCHv2 1/2] [long] improvements to limit/ulimit API and doc ((un)limit in csh emulation) Stephane Chazelas
2020-11-25 23:43 ` [PATCHv1] [long] improvements to limit/ulimit API and doc Oliver Kiddle
2020-11-26 20:14   ` [PATCH] ulimit option completions using ulimit -a output Stephane Chazelas
2020-11-27  7:13     ` Stephane Chazelas
2020-11-27  8:15       ` Felipe Contreras
2020-11-27 12:19       ` Oliver Kiddle
2021-03-27 21:25         ` Lawrence Velázquez
2021-04-03 14:57           ` Lawrence Velázquez
2021-04-10 20:11             ` Lawrence Velázquez
2021-04-13 14:35     ` Daniel Shahaf
2021-05-09 20:37       ` Lawrence Velázquez
2021-05-11 19:05         ` Stephane Chazelas
2020-11-26 20:58   ` [PATCHv2 2/2] [long] improvements to limit/ulimit API and doc (the rest) Stephane Chazelas
2020-11-27 16:39     ` Daniel Shahaf
2020-11-27 20:13       ` Stephane Chazelas
2020-11-27 20:36         ` Daniel Shahaf
2020-11-28  6:52           ` zsh coding style (was about a limit patch review) Stephane Chazelas
2020-12-01 16:47             ` Daniel Shahaf
2020-11-28  8:16         ` [PATCHv3 2/2] [long] improvements to limit/ulimit API and doc (the rest) Stephane Chazelas
2021-03-27 21:21           ` Lawrence Velázquez
2021-03-31 18:06             ` Stephane Chazelas
2020-11-26 11:19 ` [PATCHv1] [long] improvements to limit/ulimit API and doc Jun T
2020-11-26 13:55   ` Stephane Chazelas [this message]
2020-11-26 15:22     ` Jun. T
2020-11-26 17:23       ` Stephane Chazelas
2020-11-27 18:24         ` Jun. T
2020-11-27 18:34           ` Daniel Shahaf
2020-11-27 20:46           ` Stephane Chazelas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201126135523.7daayb7l543yrmcj@chazelas.org \
    --to=stephane@chazelas.org \
    --cc=takimoto-j@kba.biglobe.ne.jp \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).