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 for Android: free password hash cracker in your pocket

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

Message-ID: <3b4857e3-f2a6-104a-0370-7c41e2f755e8@gmail.com>
Date:   Mon, 27 Aug 2018 09:45:25 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     rpjday@...shcourse.ca, David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org
Subject: Re: any reason for "!!netif_carrier_ok" and "!!netif_dormant" in
 net-sysfs.c?



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.