zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@ibmth.df.unipi.it>
To: zsh-workers@math.gatech.edu (Zsh hackers list)
Subject: Re: Associative arrays and memory
Date: Sat, 14 Nov 1998 16:26:40 +0100	[thread overview]
Message-ID: <9811141526.AA19988@ibmth.df.unipi.it> (raw)
In-Reply-To: ""Bart Schaefer""'s message of "Fri, 13 Nov 1998 09:57:17 NFT." <981113095717.ZM17384@candle.brasslantern.com>

"Bart Schaefer" wrote:
> } It does seem the existing ztrdup()'s in what's now copyparam() are
> } memory leaks.  This will need fixing in any case, independently from
> } assoc arrays.
> 
> I'm not so sure any more.  When restore_params() is called, it uses the
> pm->sets functions to assign directly to the struct param already in the
> paramtab.  So that memory is now owned by the paramtab and should be
> freed when the param next becomes unset ... right?

Yes, it looks like you're right.  Maybe it's still unnecessarily
confusing.  The struct param is really just a placeholder with a type
flag for the real information.

> zagzig<17> HISTSIZE=1000 
> zagzig<18> HISTSIZE=0 echo hello
> hello
> zagzig<19> echo $HISTSIZE
> 2

This seems to be OK after restoring the old behaviour, so I haven't
look further into what had gone wrong.

> } There are currently no special assoc arrays, of course, and it should
> } probably be possible to prevent there being any
> 
> What about the discussion that started all this -- using an associative
> array to give user access to shell-internal completion data?

Rats, I just looked at zle_params.c and you're right --- they're
marked special.  I had wrongly assumed it was just a case of setting
the value at the start and using it at the end, but there tied to
functions.

That doesn't mean assoc arrays need to be the same, though.  The case
that needs worrying about is the following:

  hash=(?...?) builtin_or_func

where the ?...? represents whatever we pick for whole array
assignments.  If there is none, there's no problem; that's the only
case where copying parameters is necessary.

There's also no problem if the hash is simply used for storing
information and is not tied to special variables or functions.  You
only need a special mechanism for restoration for something like
$path, where there's an internal variable that needs setting; simply
restoring the struct param won't do that.  If we can agree that use of
assoc arrays is simply going to be by direct access to the parameter
we can avoid ever copying it: the above shell pseudocode simply makes
the supplied $hash available for the duration of builtin_func.  It
would certainly keep things much simpler, and I can provide a patch
straight away.

So, the question is are there any uses for special hashes which would
require tying them directly to an internal variable or function, or
can they always be accessed by the standard parameter functions?  I
would think the whole point of using assoc arrays is to avoid any
unpleasantness of the former kind.  Probably Sven can answer that
better than anyone.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy


  reply	other threads:[~1998-11-14 15:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-11-11  6:44 PATCH: 3.1.5 - sample associative array implementation Bart Schaefer
1998-11-11 13:58 ` Peter Stephenson
1998-11-11 14:43   ` Bruce Stephens
1998-11-11 20:00     ` Timothy Writer
1998-11-11 20:52       ` Bart Schaefer
1998-11-12  8:22         ` Timothy Writer
1998-11-12  9:23           ` Bart Schaefer
1998-11-13  0:04             ` Timothy Writer
1998-11-13  1:32               ` Bart Schaefer
1998-11-14  1:55                 ` Timothy Writer
1998-11-14  6:41                   ` Bart Schaefer
1998-11-15  8:42                     ` Timothy Writer
1998-11-15 20:03                       ` Bart Schaefer
1998-11-16 19:16                         ` Timothy Writer
1998-11-15 20:47                   ` PATCH: 3.1.5 + associative arrays under ksh emulation Bart Schaefer
1998-11-11 18:16   ` PATCH: 3.1.5 - sample associative array implementation Bart Schaefer
1998-11-13 16:16     ` Associative arrays and memory Peter Stephenson
1998-11-13 17:57       ` Bart Schaefer
1998-11-14 15:26         ` Peter Stephenson [this message]
1998-11-14 18:47           ` Bart Schaefer
1998-11-15 15:54             ` Peter Stephenson
1998-11-16  9:54 Sven Wischnowsky
1998-11-16 12:43 ` Bart Schaefer
1998-11-16 13:15 Sven Wischnowsky

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=9811141526.AA19988@ibmth.df.unipi.it \
    --to=pws@ibmth.df.unipi.it \
    --cc=zsh-workers@math.gatech.edu \
    /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).