zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Zoltan Hidvegi <hzoli@cs.elte.hu>, zsh-workers@math.gatech.edu
Subject: Re: bug (?) in 3.0-pre1
Date: Sun, 30 Jun 1996 12:21:39 -0700	[thread overview]
Message-ID: <960630122142.ZM11441@candle.brasslantern.com> (raw)
In-Reply-To: Zoltan Hidvegi <hzoli@cs.elte.hu> "Re: bug (?) in 3.0-pre1" (Jun 30,  6:13pm)

On Jun 30,  6:13pm, Zoltan Hidvegi wrote:
} Subject: Re: bug (?) in 3.0-pre1
}
} > Seems like almost any of the MUSTUSEHEAP() functions should adjust and
} > then restore the allocation strategy internally, rather than relying on
} > every caller to do so ...
} 
} But usually it is a bug if the caller use permanent allocation.  In most
} places zsh uses heap allocation.  It is an exception when a function uses
} permanent allocation and in that case it must always be very careful.

That's true, but it's at odds with the code-structure model implied by
the heapalloc()/permalloc()/lastalloc() conventions.  A function that
calls permalloc() should be able to expect the allocation strategy to
remain "permanent" locally to that function, regardless of other calls
it may make, up until one of heapalloc() or lastalloc() is called.

Similarly, a function that *knows* it needs the heap should be both able
to call and responsible for calling heapalloc() without worrying what
strategy its caller was using.  That's why lastalloc() exists; the only
problem with lastalloc() is that it's a toggle rather than a stack.

} I know that you do not like this heap very much but I still think that
} it simplifies the code and makes memory management faster.

It's not the heap itself I object to.  What I don't like is that the
allocation strategy (heap or "permanent") at any given point in the code
is *implicit* rather than *explicit*.  Because the strategy is changed
globally whenever it changes, a function calling e.g. heapalloc() can't
be sure that some other function down the call tree won't permalloc(),
thus messing up the allocation strategy expected by the caller.

If every function that ever calls heapalloc() or permalloc() were forced
to also restore the previous allocation strategy before returning, much
of this potential confusion would go away.

By the way, I applied your patch from a couple of messages back on this
thread, and yet I *still* get:

zagzig[83] cd ..
BUG: permanent allocation in doshfunc

How many of these are you going to track down before you give up and make
doshfunc() set up heap allocation on its own?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"



  reply	other threads:[~1996-06-30 19:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-06-28 17:12 gene
1996-06-28 17:50 ` Zoltan Hidvegi
1996-06-28 19:04   ` Steven L Baur
1996-06-29 19:13   ` Bart Schaefer
1996-06-30 16:13     ` Zoltan Hidvegi
1996-06-30 19:21       ` Bart Schaefer [this message]
1996-06-30 21:50         ` Action, not words (Re: bug (?) in 3.0-pre1) Bart Schaefer
1996-07-02  7:24           ` Sick macros (was: Action, not words (Re: bug (?) in 3.0-pre1)) Zefram
1996-07-02 17:52             ` Bart Schaefer
1996-07-02 18:24               ` Zefram
1996-07-02 19:19                 ` Bart Schaefer

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=960630122142.ZM11441@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=hzoli@cs.elte.hu \
    --cc=schaefer@nbn.com \
    --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).