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]
Message-ID: <20150524081018.GB17508@opentech.at>
Date:	Sun, 24 May 2015 10:10:18 +0200
From:	Nicholas Mc Guire <der.herr@...r.at>
To:	Joe Perches <joe@...ches.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Nicholas Mc Guire <hofrat@...dl.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Josh Triplett <josh@...htriplett.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] rcu: change return type to bool

On Sun, 24 May 2015, Joe Perches wrote:

> On Sun, 2015-05-24 at 09:27 +0200, Nicholas Mc Guire wrote:
> > On Sat, 23 May 2015, Steven Rostedt wrote:
> []
> > > > -	return sum;
> > > > +	return !!sum;
> > > 
> > > Hmm I wonder if gcc is smart enough to do the above without the need
> > > for !!? That is, will it turn to !! because the return of the function
> > > is bool, or does gcc complain about it not being bool without the !!?
> > > Not a criticism of the patch, just a curiosity.
> > >
> > gcc will not complain if you assign a unsigned long to a boolean
> > as I understand it it is a macro and is not doing any type 
> > checking/promotion at all - so anything can be assigned to a bool
> > without warning (including double and pointers).
> > The !! will though always make the type compatible with int so it is 
> > a well defined type atleast as far as __builtin_types_compatible_p()
> > goes, and !! also makes static code checkers happy (that are maybe not
> > as smart as gcc) and it does make the intent of sum being treated 
> > as boolean here clear.
> 
> 6.3.1.2 Boolean type
> 
> When any scalar value is converted to _Bool, the result is 0 if the
> value compares equal to 0; otherwise, the result is 1.
>
As I understand this applies to arithmetic operations so for
bool x = false; int i = 42; x += i; x is defined to be true
but here it is the return type and not an arithmetic operation
so does this apply here without the !!?

the !! is ensuring that it is of type compatible to int as the rank
of _Bool is the lowest and

6.3.1 Arithmetic operands
6.3.1.1 Boolean, characters, and integers
...
2 The following may be used in an expression wherever an int or unsigned 
  int may be used:
  - An object or expression with an integer type whose integer conversion 
    rank is less than the rank of int and unsigned int.
  ...
"If an int can represent all values of the original type, the value is
 converted to an int; otherwise, it is converted to an unsigned int. 
 These are called the integer promotions.48) All other types are 
 unchanged by the integer promotions."


thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ