Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] Fix a few coding standards violations in infptrace.c
Date: Sun, 21 Oct 2001 07:54:00 -0000	[thread overview]
Message-ID: <200110211453.f9LErps11151@delius.kettenis.local> (raw)

Checked in as obvious.

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* infptrace.c (child_xfer_memory): Fix a few coding standards
	violations.

Index: infptrace.c
===================================================================
RCS file: /cvs/src/src/gdb/infptrace.c,v
retrieving revision 1.17
diff -u -p -r1.17 infptrace.c
--- infptrace.c 2001/07/26 02:23:57 1.17
+++ infptrace.c 2001/10/21 14:50:06
@@ -476,40 +476,38 @@ store_inferior_registers (int regno)
 
 #if !defined (CHILD_XFER_MEMORY)
 /* NOTE! I tried using PTRACE_READDATA, etc., to read and write memory
-   in the NEW_SUN_PTRACE case.
-   It ought to be straightforward.  But it appears that writing did
-   not write the data that I specified.  I cannot understand where
-   it got the data that it actually did write.  */
-
-/* Copy LEN bytes to or from inferior's memory starting at MEMADDR
-   to debugger memory starting at MYADDR.   Copy to inferior if
-   WRITE is nonzero.  TARGET is ignored.
-
-   Returns the length copied, which is either the LEN argument or zero.
-   This xfer function does not do partial moves, since child_ops
-   doesn't allow memory operations to cross below us in the target stack
-   anyway.  */
+   in the NEW_SUN_PTRACE case.  It ought to be straightforward.  But
+   it appears that writing did not write the data that I specified.  I
+   cannot understand where it got the data that it actually did write.  */
+
+/* Copy LEN bytes to or from inferior's memory starting at MEMADDR to
+   debugger memory starting at MYADDR.  Copy to inferior if WRITE is
+   nonzero.  TARGET is ignored.
+
+   Returns the length copied, which is either the LEN argument or
+   zero.  This xfer function does not do partial moves, since
+   child_ops doesn't allow memory operations to cross below us in the
+   target stack anyway.  */
 
 int
 child_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write,
 		   struct mem_attrib *attrib ATTRIBUTE_UNUSED,
 		   struct target_ops *target)
 {
-  register int i;
+  int i;
   /* Round starting address down to longword boundary.  */
-  register CORE_ADDR addr = memaddr & -(CORE_ADDR) sizeof (PTRACE_XFER_TYPE);
+  CORE_ADDR addr = memaddr & -(CORE_ADDR) sizeof (PTRACE_XFER_TYPE);
   /* Round ending address up; get number of longwords that makes.  */
-  register int count
-  = (((memaddr + len) - addr) + sizeof (PTRACE_XFER_TYPE) - 1)
-  / sizeof (PTRACE_XFER_TYPE);
+  int count = ((((memaddr + len) - addr) + sizeof (PTRACE_XFER_TYPE) - 1)
+	       / sizeof (PTRACE_XFER_TYPE));
   /* Allocate buffer of that many longwords.  */
-  register PTRACE_XFER_TYPE *buffer
-  = (PTRACE_XFER_TYPE *) alloca (count * sizeof (PTRACE_XFER_TYPE));
+  PTRACE_XFER_TYPE *buffer =
+    (PTRACE_XFER_TYPE *) alloca (count * sizeof (PTRACE_XFER_TYPE));
 
   if (write)
     {
-      /* Fill start and end extra bytes of buffer with existing memory data.  */
-
+      /* Fill start and end extra bytes of buffer with existing memory
+         data.  */
       if (addr != memaddr || len < (int) sizeof (PTRACE_XFER_TYPE))
 	{
 	  /* Need part of initial word -- fetch it.  */
@@ -517,23 +515,19 @@ child_xfer_memory (CORE_ADDR memaddr, ch
 			      (PTRACE_ARG3_TYPE) addr, 0);
 	}
 
-      if (count > 1)		/* FIXME, avoid if even boundary */
+      if (count > 1)		/* FIXME, avoid if even boundary.  */
 	{
-	  buffer[count - 1] 
-	    = ptrace (PT_READ_I, PIDGET (inferior_ptid),
-		      ((PTRACE_ARG3_TYPE)
-		       (addr + (count - 1) * sizeof (PTRACE_XFER_TYPE))),
-		      0);
+	  buffer[count - 1] =
+	    ptrace (PT_READ_I, PIDGET (inferior_ptid),
+		    ((PTRACE_ARG3_TYPE)
+		     (addr + (count - 1) * sizeof (PTRACE_XFER_TYPE))), 0);
 	}
-
-      /* Copy data to be written over corresponding part of buffer */
 
+      /* Copy data to be written over corresponding part of buffer.  */
       memcpy ((char *) buffer + (memaddr & (sizeof (PTRACE_XFER_TYPE) - 1)),
-	      myaddr,
-	      len);
+	      myaddr, len);
 
       /* Write the entire buffer.  */
-
       for (i = 0; i < count; i++, addr += sizeof (PTRACE_XFER_TYPE))
 	{
 	  errno = 0;
@@ -556,7 +550,7 @@ child_xfer_memory (CORE_ADDR memaddr, ch
     }
   else
     {
-      /* Read all the longwords */
+      /* Read all the longwords.  */
       for (i = 0; i < count; i++, addr += sizeof (PTRACE_XFER_TYPE))
 	{
 	  errno = 0;
@@ -572,6 +566,7 @@ child_xfer_memory (CORE_ADDR memaddr, ch
 	      (char *) buffer + (memaddr & (sizeof (PTRACE_XFER_TYPE) - 1)),
 	      len);
     }
+
   return len;
 }
 \f


                 reply	other threads:[~2001-10-21  7:54 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=200110211453.f9LErps11151@delius.kettenis.local \
    --to=kettenis@wins.uva.nl \
    --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