From: Peter Stephenson <Peter.Stephenson@csr.com>
To: "Zsh Hackers' List" <zsh-workers@zsh.org>
Subject: Re: MAX_ARRLEN
Date: Tue, 24 Apr 2012 14:37:06 +0100 [thread overview]
Message-ID: <20120424143706.3ccc490d@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <120423093812.ZM5059@torch.brasslantern.com>
On Mon, 23 Apr 2012 09:38:12 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Apr 23, 4:27pm, Peter Stephenson wrote:
> } What's the right thing to do? There are various grades ranging from
> } making it compilable out, through making it compile-time configurable
> } with an option to compile out, through making it an option to have the
> } check turned on, to having a variable that we check using getiparam()
> } each time, to having a special variable so that we don't need to get it
> } each time. I think the last option with a clearly named variable such
> } as ZSH_MAX_ARRAY_LENGTH that can be set to 0 to turn it off is probably
> } the best.
>
> I think something based on one of the process limits would be good.
> Maybe combined with stashing it in a variable that can be modified.
> Maybe even putting that variable in a module so it's not visible in a
> barebones shell.
>
> datasize, stacksize, and addressspace are all candidates for how to
> figure out the limit. (Do we ever allocate arrays for zsh parameter
> expansion on the stack?)
I don't really know how to estimate the array size, however, since it
consists of the array length and the size occupied by each element, and
it depends what the elements are doing. So the relationship between the
limit and the size of the array is very vague, to the point where I'm
not sure if it's useful. Nor is it clear to me that basing per-array
limits on global limits is useful --- it's only helpful in practice if
you've got one, single large array. If you treat as some sort of finger
in the air estimate as to how much space the user is likely to be able
to cram into an array, I'm still not sure you can do it well enough to
make it useful. Furthermore, here are my limits (which, like most
users, I haven't touched):
cputime unlimited
filesize unlimited
datasize unlimited
stacksize 8MB
coredumpsize unlimited
memoryuse unlimited
maxproc 1024
descriptors 1024
memorylocked 64kB
addressspace unlimited
maxfilelocks unlimited
sigpending 15927
msgqueue 819200
nice 0
rt_priority 0
The only relevant useful one is stacksize; but array length doesn't have
direct implications for the stack.
So I don't see anything I personally would be able to implement here,
though if anyone else has ideas they're certainly welcome to look.
Indeed, given the original intention, is it actually useful to apply the
limit to anything other than the argument array?
As something to do now, I'd be tempted either to "#if 0" the code until
someone can come up with a replacement that is demonstrably useful, or
implement $ZSH_MAX_ARRAY_LENGTH and initialise it to 0 (no limit),
applying it at the current definitely non-optimal location. Either
option at least gives us something basic usable, which the current code
isn't really. Anything beyond that still seems to be somewhat
ill-defined and I'd like finally to have something non-broken ASAP.
--
Peter Stephenson <pws@csr.com> Software Engineer
Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
next prev parent reply other threads:[~2012-04-24 14:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-23 15:27 MAX_ARRLEN Peter Stephenson
2012-04-23 16:10 ` MAX_ARRLEN Mikael Magnusson
2012-04-23 16:21 ` MAX_ARRLEN Bart Schaefer
2012-04-23 16:27 ` MAX_ARRLEN Peter Stephenson
2012-04-23 16:36 ` MAX_ARRLEN Mikael Magnusson
2012-04-23 16:40 ` MAX_ARRLEN Peter Stephenson
2012-04-23 16:45 ` MAX_ARRLEN Mikael Magnusson
2012-04-23 16:38 ` MAX_ARRLEN Bart Schaefer
2012-04-24 13:37 ` Peter Stephenson [this message]
2012-04-24 19:45 ` MAX_ARRLEN Bart Schaefer
2012-04-25 9:01 ` MAX_ARRLEN Peter Stephenson
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=20120424143706.3ccc490d@pwslap01u.europe.root.pri \
--to=peter.stephenson@csr.com \
--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).