Re: [PATCHv1] [long] improvements to limit/ulimit API and doc

[Jun T <takimoto-j@kba.biglobe.ne.jp>]

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



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