[RFC] ARI fix: Replace sys/wait.h by gdb_wait.h in linux-fork.c

[RFC] ARI fix: Replace sys/wait.h by gdb_wait.h in linux-fork.c

[Pierre Muller]

  - This is a RFC and not a RFA for several reasons:
1) I have no access to a linux machine, and even building
a gdb with linux target does not include that source.
So someone should test and tell me if the
patch is without regressions.

2) Are there rules about the order in which
the different headers are listed?
  You need to remember that I am
mainly a pascal programmer. In pascal language,
exchanging the order in the USES clause,
can leads to the fact that another function
is used in the source if the same function
is declared in the two included units.
  As this is not allowed in C, I suppose that this is
not relevant, but with all that macros that get defined
when parsing the headers, I am still not sure it is really
safe to put the headers in a random order.

  I did put the gdb_wait.h together with other local
headers, which seems to be a common practice in GDB sources.
Is this part of coding style, or something more profound?

3) I also updated the dependency of linux-fork.o in
Makefile.in, but stumbled on the same problem:
is there some preferred ordering of the dependency list?
I did not see something obvious  ...
Does it follow the declaration order in the source?



Pierre Muller,
trying to reduce ARIs...

ChangeLog entry:
2007-10-04  Pierre Muller  <muller@ics.u-strasbg.fr>

        * linux-fork.c: ARI fix: include "gdb_wait.h" instead of
<sys/wait.h>.
        Makefile.in (linux-fork.o): Add gdb_wait.h dependency.

$ cvs diff -up linux-fork.c Makefile.in
Index: linux-fork.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-fork.c,v
retrieving revision 1.12
diff -u -p -r1.12 linux-fork.c
--- linux-fork.c        23 Aug 2007 18:08:35 -0000      1.12
+++ linux-fork.c        5 Oct 2007 07:31:45 -0000
@@ -26,9 +26,9 @@
 #include "gdb_string.h"
 #include "linux-fork.h"
 #include "linux-nat.h"
+#include "gdb_wait.h"

 #include <sys/ptrace.h>
-#include <sys/wait.h>
 #include <sys/param.h>
 #include <dirent.h>
 #include <ctype.h>
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.939
diff -u -p -r1.939 Makefile.in
--- Makefile.in 27 Sep 2007 18:48:32 -0000      1.939
+++ Makefile.in 5 Oct 2007 07:31:46 -0000
@@ -2236,7 +2236,7 @@ linespec.o: linespec.c $(defs_h) $(symta
        $(objc_lang_h) $(linespec_h) $(exceptions_h) $(language_h)
 linux-fork.o: linux-fork.c $(defs_h) $(inferior_h) $(regcache_h)
$(gdbcmd_h) \
        $(infcall_h) $(gdb_assert_h) $(gdb_string_h) $(linux_fork_h) \
-       $(linux_nat_h)
+       $(linux_nat_h) $(gdb_wait_h)
 linux-nat.o: linux-nat.c $(defs_h) $(inferior_h) $(target_h)
$(gdb_string_h) \
        $(gdb_wait_h) $(gdb_assert_h) $(linux_nat_h) $(gdbthread_h) \
        $(gdbcmd_h) $(regcache_h) $(regset_h) $(inf_ptrace_h) $(auxv_h) \

Re: [RFC] ARI fix: Replace sys/wait.h by gdb_wait.h in linux-fork.c

[Joel Brobecker]

Hello Pascal,

> 2007-10-04  Pierre Muller  <muller@ics.u-strasbg.fr>
> 
>         * linux-fork.c: ARI fix: include "gdb_wait.h" instead of <sys/wait.h>.
>         Makefile.in (linux-fork.o): Add gdb_wait.h dependency.

This patch is OK. I ran it against the regression testsuite just
to double-check.

> 2) Are there rules about the order in which
> the different headers are listed?

There are some rules, like "defs.h" should always be included first.

Usually speaking, in C, I always try to write include files in a way
that the order in which I include them is not important. To the best
or my knowledge, GDB also tries to accomplish that.

> I did put the gdb_wait.h together with other local
> headers, which seems to be a common practice in GDB sources.

That's perfect.

> 3) I also updated the dependency of linux-fork.o in
> Makefile.in, but stumbled on the same problem:
> is there some preferred ordering of the dependency list?

I don't know if there is a prefered ordering. Definitely, the ordering
in the makefile does not matter, but I try to maintain the dependency
list in the same order as the includes. It makes it a lot simpler to
double-check that the list is still accurate. So your change is great.

> trying to reduce ARIs...

Thanks!

-- 
Joel

RE: [RFC] ARI fix: Replace sys/wait.h by gdb_wait.h in linux-fork.c

[Pierre Muller]

Thanks, committed.

Pierre Muller

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Joel Brobecker
> Sent: Friday, October 05, 2007 10:02 PM
> To: Pierre Muller
> Cc: gdb-patches@sourceware.org
> Subject: Re: [RFC] ARI fix: Replace sys/wait.h by gdb_wait.h in linux-
> fork.c
> 
> Hello Pascal,
> 
> > 2007-10-04  Pierre Muller  <muller@ics.u-strasbg.fr>
> >
> >         * linux-fork.c: ARI fix: include "gdb_wait.h" instead of
> <sys/wait.h>.
> >         Makefile.in (linux-fork.o): Add gdb_wait.h dependency.
> 
> This patch is OK. I ran it against the regression testsuite just
> to double-check.
> 
> > 2) Are there rules about the order in which
> > the different headers are listed?
> 
> There are some rules, like "defs.h" should always be included first.
> 
> Usually speaking, in C, I always try to write include files in a way
> that the order in which I include them is not important. To the best
> or my knowledge, GDB also tries to accomplish that.
> 
> > I did put the gdb_wait.h together with other local
> > headers, which seems to be a common practice in GDB sources.
> 
> That's perfect.
> 
> > 3) I also updated the dependency of linux-fork.o in
> > Makefile.in, but stumbled on the same problem:
> > is there some preferred ordering of the dependency list?
> 
> I don't know if there is a prefered ordering. Definitely, the ordering
> in the makefile does not matter, but I try to maintain the dependency
> list in the same order as the includes. It makes it a lot simpler to
> double-check that the list is still accurate. So your change is great.
> 
> > trying to reduce ARIs...
> 
> Thanks!
> 
> --
> Joel