Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: PATCH: allocate namecopy on heap, not stack
Date: Fri, 29 Apr 2005 21:38:00 -0000	[thread overview]
Message-ID: <vt264y5feqg.fsf@zenia.home> (raw)


Committed as obvious.

2005-04-28  Jim Blandy  <jimb@redhat.com>

	* parse.c (namecopy): Change allocation conventions.
	(namecopy_size): New variable.
	(copy_name): Allocate namecopy using xrealloc, instead of assuming
	it has adequate space allocated to it.
	(parse_exp_1): Don't try to allocate space for namecopy here.

Index: gdb/parse.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/parse.c,v
retrieving revision 2.105
diff -c -p -r2.105 parse.c
*** gdb/parse.c	13 Apr 2004 16:38:57 -0000	2.105
--- gdb/parse.c	28 Apr 2005 23:58:49 -0000
*************** union type_stack_elt *type_stack;
*** 89,97 ****
  int type_stack_depth, type_stack_size;
  char *lexptr;
  char *prev_lexptr;
- char *namecopy;
  int paren_depth;
  int comma_terminates;
  \f
  static int expressiondebug = 0;
  
--- 89,106 ----
  int type_stack_depth, type_stack_size;
  char *lexptr;
  char *prev_lexptr;
  int paren_depth;
  int comma_terminates;
+ 
+ /* A temporary buffer for identifiers, so we can null-terminate them.
+ 
+    We allocate this with xrealloc.  parse_exp_1 used to allocate with
+    alloca, using the size of the whole expression as a conservative
+    estimate of the space needed.  However, macro expansion can
+    introduce names longer than the original expression; there's no
+    practical way to know beforehand how large that might be.  */
+ char *namecopy;
+ size_t namecopy_size;
  \f
  static int expressiondebug = 0;
  
*************** find_template_name_end (char *p)
*** 769,776 ****
--- 778,793 ----
  char *
  copy_name (struct stoken token)
  {
+   /* Make sure there's enough space for the token.  */
+   if (namecopy_size < token.length + 1)
+     {
+       namecopy_size = token.length + 1;
+       namecopy = xrealloc (namecopy, token.length + 1);
+     }
+       
    memcpy (namecopy, token.ptr, token.length);
    namecopy[token.length] = 0;
+ 
    return namecopy;
  }
  \f
*************** parse_exp_1 (char **stringptr, struct bl
*** 1045,1051 ****
    else
      expression_context_block = get_selected_block (&expression_context_pc);
  
-   namecopy = (char *) alloca (strlen (lexptr) + 1);
    expout_size = 10;
    expout_ptr = 0;
    expout = (struct expression *)
--- 1062,1067 ----


             reply	other threads:[~2005-04-29 21:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-29 21:38 Jim Blandy [this message]
2005-04-29 21:39 ` Daniel Jacobowitz
2005-04-29 22:54   ` Jim Blandy
2005-04-29 23:56     ` Daniel Jacobowitz

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=vt264y5feqg.fsf@zenia.home \
    --to=jimb@redhat.com \
    --cc=gdb-patches@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