netdev - Re: any reason for "!!netif_carrier_ok" and "!!netif

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 27 Aug 2018 12:50:44 -0400
From:   rpjday@...shcourse.ca
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: any reason for "!!netif_carrier_ok" and "!!netif_dormant" in
 net-sysfs.c?


Quoting Eric Dumazet <eric.dumazet@...il.com>:

> On 08/27/2018 09:16 AM, rpjday@...shcourse.ca wrote:
>>
>> Quoting David Miller <davem@...emloft.net>:
>>
>>> From: "Robert P. J. Day" <rpjday@...shcourse.ca>
>>> Date: Mon, 27 Aug 2018 04:55:29 -0400 (EDT)
>>>
>>>>   another pedantic oddity -- is there a reason for these two double
>>>> negations in net/core/net-sysfs.c?
>>>
>>> It turns an arbitrary integer into a boolean, this is a common
>>> construct across the kernel tree so I'm surprised you've never seen
>>> it before.
>>>
>>> Although, I don't know how much more hand holding we're willing to
>>> tolerate continuing to give to you at this point.
>>>
>>> Thanks.
>>
>>   I mentioned in my earlier email that I know what that construct is
>> *typically* used for; I also pointed out that, AFAICT, it was totally
>> unnecessary in the context of the two routines I mentioned, which
>> would appear to ever return only one of two boolean values, 0 or 1.
>>
>>   My experience with kernel code is that one should not introduce
>> unnecessary complexities, which suggests (as I stated) that there
>> seems to be no value in the "!!" construct *in those particular
>> cases*, hence my curiosity.
>
> Have you checked git history ?
>
> My guess is that netif_carrier_ok() used to return an int, not a bool.
>
> !!netif_carrier_ok() was not complexity, it was probably shorter than
> the form used in
>
> u32 ethtool_op_get_link(struct net_device *dev)
> {
> 	return netif_carrier_ok(dev) ? 1 : 0;
> }
>
> But really, this is really trivial stuff, we have more interesting stuff
> to take care of these days.

   Point taken -- for trivialities like this, I'll check Git history, and
apologies for the noise on that one.

rday