[Libvir] [PATCH] * qemud/remote.c: Don't include <getopt.h>. Not used.

[Jim Meyering]

"Daniel P. Berrange" <berrange at redhat.com> wrote:

> On Wed, Mar 19, 2008 at 01:50:27PM +0000, Richard W.M. Jones wrote:
>> On Wed, Mar 19, 2008 at 01:25:33PM +0000, Daniel P. Berrange wrote:
>> > On Wed, Mar 19, 2008 at 01:11:18PM +0000, Richard W.M. Jones wrote:
>> > > On Wed, Mar 19, 2008 at 02:08:44PM +0100, Jim Meyering wrote:
>> > > > I had a few in-progress changes from a week or two ago,
>> > > > and am clearing the decks.
>> > > >
>> > > > I added a new build-checking rule (coming separately)
>> > > > and it exposed an unnecessary include:
>> > >
>> > > +1
>> > >
>> > > So we have a way to find header files which are unused?
>> >
>> > No - this is impossible unless you have a copy of every OS we've ever
>> > tested on. It may be unused on Linux, but may be needed on Solaris, etc
>> > etc. Removing <getopt.h> is an obviously safe action, but in general
>> > we should be wary of removing supposedly unused heads.
>>
>> Surely we can do it for POSIX calls?
>>
>> Of course the OS / libc itself may not obey POSIX ...
>
> Yeah, I'm not convinced any OS is fully compliant with POSIX header file
> definitions - particularly when you get into more obscure platforms like
> win32/cygwin, or even just slightly older Linux. And we're compiling with
> the _USE_GNU extension defined so the headers we're including on Linux
> aren't even in POSIX compliant mode anyway

It is obviously feasible to detect at least some unused headers.
Just be very careful before removing any #include directive
that a new check claims is unused.

Obviously there's a cost/gain trade-off.
E.g. my existing getopt check is sloppy in that it doesn't
bother checking for optind or opterr, or any of the other
symbols typically defined in getopt.h.  It just checks for
the regexp '\<getopt(_long)? *(', since so far that has been
sufficient.