Re: Change in wireshark[master]: Remove unneeded #includes from epan/dissectors

[Martin Mathieson <martin.r.mathieson () googlemail com>]

This makes good sense to me, Bill.  I was having too much fun with my
python script to look carefully look at the bigger picture.

I didn't realise how many header files <epan/packet.h> already pulls in.
In particular, it indirectly includes glib.h (through column-utils.h), so
we should remove #include <glib.h> from packet-PROTOABBREV.c.

In my script, I carefully avoid removing header files includes that were
inside #if or #ifdef.  But packet-aruba-papi.c and packet-mrcpv2.c seem to
have actually retained this from packet-PROTOABBREV.c:

#if 0
/* Include only as needed */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
...
#endif


I will wait until you have gone through and checked for checking
epan/packet.h, then run my script once more.  If no-one else beats me to
it, I will also fix up the issues above, but its too late tonight.

Martin




On Fri, Dec 19, 2014 at 9:19 PM, Bill Meier <wmeier () newsguy com> wrote:

> On 12/19/2014 12:05 PM, Martin Mathieson (Code Review) wrote:
>
> > Change subject: Remove unneeded #includes from epan/dissectors
> > ......................................................................
> >
> > Remove unneeded #includes from epan/dissectors
> Martin:
>
> Obviously, #includes usage in dissectors is a bit of a mish-mosh
>
> There's one thing I would think worthwhile to do to try to keep the
> #includes a bit under control and somewhat consistent before going through
> the dissectors to remove unneeded #includes.
>
> That is, I would change the dissectors as needed to
> have '#include <epan/packet.h>' as the first #include (after config.h and
> any "system" includes).
>
> If this is done, the #includes (direct and indirect) in packet.h can then
> be immediately removed from the dissectors.
>
>
> Of the ~1130 non-generated .c files in epan/dissectors, there's about 350
> which don't have '#include <epan/packet.h>' at all and maybe another 50
> which don't have the include as the first wireshark include.
>
>
> If you and others are Ok with this suggestion, I'd be happy to do that
> work (altho it might take me a day or three).
>
> Bill
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe