public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifixinc.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: binutils@sources.redhat.com
Subject: Re: [PATCH] ia64 unwind directive semantics
Date: Fri, 11 Feb 2005 01:39:00 -0000	[thread overview]
Message-ID: <1108078835.24473.106.camel@aretha.corp.specifixinc.com> (raw)
In-Reply-To: <s200e912.057@emea1-mh.id2.novell.com>

On Wed, 2005-02-02 at 06:52, Jan Beulich wrote:
>        hash_delete (md.dynreg_hash, dr->name);
> +      obstack_free (&notes, (void *) dr->name);

I don't believe this is safe.  obstacks are stack based.  When you call
obstack_free, not only does it free dr->name, but also everything newer
than it.  There is no guarantee that everything newer than dr->name is
unused.  This is very unlikely to be the case.  There could have been an
obstack call used for something else (non hash table) in the meantime.

There is also an efficiency issue here, as the right way to free these
string if we could would be with a single obstack_free call, for the
oldest string.  Calling obstack_free on each string means we are freeing
them multiple times, which is probably not good.

This is different than the demand_copy_C_string case, as in that case we
know that there is no other obstack allocation between the
demand_copy_C_string call and the obstack_free.

If we want to be able to free these strings here, then we can't use
obstack to allocate them.

>  	  as_bad ("Attempt to redefine register set `%s'", name);
> +	  obstack_free (&notes, name);

This one is safe, because we know that there are no other allocations on
the notes obstack since this string was allocated.

The rest of the patch looks OK.  This is your ia64-pound patch.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


  reply	other threads:[~2005-02-10 23:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-02 14:52 Jan Beulich
2005-02-11  1:39 ` James E Wilson [this message]
     [not found] <s20ca004.024@emea1-mh.id2.novell.com>
2005-02-11 23:15 ` James E Wilson
  -- strict thread matches above, loose matches on Subject: below --
2005-02-11 15:58 Jan Beulich
2005-02-02 13:56 Jan Beulich
     [not found] <s1fa08eb.028@emea1-mh.id2.novell.com>
2005-01-29  1:49 ` James E Wilson
2005-01-28  9:43 Jan Beulich
2005-01-24 11:29 Jan Beulich
2005-01-28  3:52 ` James E Wilson
2005-02-02  8:16 ` Alan Modra

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=1108078835.24473.106.camel@aretha.corp.specifixinc.com \
    --to=wilson@specifixinc.com \
    --cc=JBeulich@novell.com \
    --cc=binutils@sources.redhat.com \
    /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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).