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 <[email protected]> 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 <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
