gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] [PATCH] Remove duplicate <sys/socket.h> include.


From: Robert Norris
Subject: Re: [gpsd-dev] [PATCH] Remove duplicate <sys/socket.h> include.
Date: Tue, 8 Mar 2016 22:52:27 +0000



>
> On Mon, 7 Mar 2016, Rob Norris wrote:
>
>> TESTED
>> 'scons build-all check' with and without qt passes.
>> ---
>> libgps_sock.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/libgps_sock.c b/libgps_sock.c
>> index 169a900..d056515 100644
>> --- a/libgps_sock.c
>> +++ b/libgps_sock.c
>> @@ -17,7 +17,6 @@
>> #include <sys/types.h>
>> #include <sys/stat.h>
>> #include <sys/select.h>
>> -#include <sys/socket.h>
>> #include <unistd.h>
>>
>> #ifndef USE_QT
>> --
>> 2.7.0
>>
>>
>>
>
> Well, it certainly doesn't need to include it twice. :-)
>
> But the real question is which definition should be removed. It's good
> practice to always directly include any header that's directly used,
> regardless of whether it's also indirectly included via some other header
> (and of course the duplicate inclusion is filtered out by the guard
> check). So if the code makes any use of socket.h definitions in the
> USE_QT case, it's preferable to keep the unconditional include and remove
> the conditional one. If it *only* uses Qt's socket definitions in the
> USE_QT case, then removing the unconditional include is fine.
>
> You can't tell the difference by checking for build errors; it's just that
> relying on indirect includes is more fragile.
>
> Fred Wright

I'm positive that the code doesn't require any socket.h definitions (nor any 
indirect includes) in the USE_QT case.

There's no build warnings either.

However for absolute guarantee of not effecting the built code, removing the 
second instance is safer.

The main reason for this tidy up is that socket.h doesn't exist on Windows and 
thus needs to #ifdef'd out.
Obviously having more #ifdef's makes the code more messy (select.h is also not 
available on Windows either)

                                          


reply via email to

[Prev in Thread] Current Thread [Next in Thread]