Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] zero-terminate result of target_read_alloc
Date: Tue, 18 Jul 2006 09:56:00 -0000	[thread overview]
Message-ID: <200607181356.16071.vladimir@codesourcery.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 327 bytes --]


This patch makes result of target_read_alloc zero-terminated.
The point is that often the object is not allowed to contain embedded zeros,
and working with zero-terminated strings is much easier.

OK?

- Volodya

2006-07-18  Vladimir Prus  <vladimir@codesourcery.com>

	* target.c (target_read_alloc): Zero-terminate result.


[-- Attachment #2: 2_target_read_alloc_zero_terminate.diff --]
[-- Type: text/x-diff, Size: 1449 bytes --]

--- target.c	(revision 174)
+++ target.c	(revision 175)
@@ -1413,6 +1413,11 @@ target_write (struct target_ops *ops,
    sufficiently large buffer will be allocated using xmalloc and
    returned in *BUF_P containing the contents of the object.
 
+   The content will be zero terminated.  The caller should consider 
+   if object can legitimately contain embedded zero, and either use 
+   string operations, or use the returned object length when 
+   manupulating the buffer.
+
    This method should be used for objects sufficiently small to store
    in a single xmalloc'd buffer, when no fixed bound on the object's
    size is known in advance.  Don't try to read TARGET_OBJECT_MEMORY
@@ -1442,7 +1447,7 @@ target_read_alloc (struct target_ops *op
   while (1)
     {
       n = target_read_partial (ops, object, annex, &buf[buf_pos],
-			       buf_pos, buf_alloc - buf_pos);
+			       buf_pos, buf_alloc - buf_pos - 1);
       if (n < 0)
 	{
 	  /* An error occurred.  */
@@ -1455,14 +1460,17 @@ target_read_alloc (struct target_ops *op
 	  if (buf_pos == 0)
 	    xfree (buf);
 	  else
-	    *buf_p = buf;
+            {
+              buf[buf_pos] = '\0';
+              *buf_p = buf;
+            }
 	  return buf_pos;
 	}
 
       buf_pos += n;
 
       /* If the buffer is filling up, expand it.  */
-      if (buf_alloc < buf_pos * 2)
+      if (buf_pos >= buf_alloc - 1)
 	{
 	  buf_alloc *= 2;
 	  buf = xrealloc (buf, buf_alloc);

             reply	other threads:[~2006-07-18  9:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-18  9:56 Vladimir Prus [this message]
2006-07-18 11:25 ` Mark Kettenis
2006-07-18 11:33   ` Vladimir Prus
2006-07-18 12:34   ` Daniel Jacobowitz
2006-07-18 13:15     ` Mark Kettenis
2006-07-18 13:39       ` Daniel Jacobowitz
2006-07-18 13:51         ` Vladimir Prus
2006-07-18 19:51           ` Jim Blandy
2006-07-24  4:09   ` Daniel Jacobowitz
2006-07-24 21:41     ` Mark Kettenis
2006-07-24 22:00       ` Daniel Jacobowitz
2006-07-26 21:53         ` Mark Kettenis
2006-07-26 22:25           ` Daniel Jacobowitz
2006-07-26 22:36             ` Mark Kettenis
2006-07-27 21:25               ` 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=200607181356.16071.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.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