Re: [PATCH] Minor reformatting in infrun.c

[Joel Brobecker <brobecker@gnat.com>]

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

> Err, I was actually meaning to say "let's conform with indent", 
> rather than "let's defeat indent".  How about moving the comment
> outside the argument list?  Then the args can stay as they were.

I see what you mean now. I should have tried it before, instead of
assuming that moving the comment up would not prevent indent from
formatting the args back to the same previous unreadable way (I did not
realize that the comment had this effect in the formatting result)...

I can commit the following patch. I verified that a later re-indent
does not cause a formatting change in the second argument.

2002-08-23  Joel Brobecker  <brobecker@gnat.com>

        * infrun.c (handle_inferior_event): Move a comment outside of a
        function call, in order to avoid indent reformatting this part
        of the code in an unreadable way.

-- 
Joel

[-- Attachment #2: infrun.c.diff --]
[-- Type: text/plain, Size: 2392 bytes --]

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.68
diff -c -3 -p -r1.68 infrun.c
*** infrun.c	20 Aug 2002 23:01:29 -0000	1.68
--- infrun.c	23 Aug 2002 16:17:49 -0000
*************** handle_inferior_event (struct execution_
*** 2110,2127 ****
  	     This is only important on targets where DECR_PC_AFTER_BREAK
  	     is non-zero.  The prev_pc test is meant to distinguish between
  	     singlestepping a trap instruction, and singlestepping thru a
! 	     jump to the instruction following a trap instruction. */
  
  	  stop_bpstat =
              bpstat_stop_status
                (&stop_pc,
-                /* Pass TRUE if our reason for stopping is something other
-                   than hitting a breakpoint.  We do this by checking that
-                   either we detected earlier a software single step trap or
-                   1) stepping is going on and 2) we didn't hit a breakpoint
-                   in a signal handler without an intervening stop in
-                   sigtramp, which is detected by a new stack pointer value
-                   below any usual function calling stack adjustments.  */
                 sw_single_step_trap_p
                 || (currently_stepping (ecs)
                     && prev_pc != stop_pc - DECR_PC_AFTER_BREAK
--- 2110,2127 ----
  	     This is only important on targets where DECR_PC_AFTER_BREAK
  	     is non-zero.  The prev_pc test is meant to distinguish between
  	     singlestepping a trap instruction, and singlestepping thru a
! 	     jump to the instruction following a trap instruction.
  
+            Therefore, pass TRUE if our reason for stopping is
+            something other than hitting a breakpoint.  We do this by
+            checking that either: we detected earlier a software single
+            step trap or, 1) stepping is going on and 2) we didn't hit
+            a breakpoint in a signal handler without an intervening stop
+            in sigtramp, which is detected by a new stack pointer value
+            below any usual function calling stack adjustments.  */
  	  stop_bpstat =
              bpstat_stop_status
                (&stop_pc,
                 sw_single_step_trap_p
                 || (currently_stepping (ecs)
                     && prev_pc != stop_pc - DECR_PC_AFTER_BREAK