!!, what is it?

[bjk of course]

hello,

I've stumbled upon this in some code:

n = !!x;

I've ran it and 'n' is always either 0 or 1. Is '!!' an operator (what's it
called?) and is it standard/portable?

 

[Alexei A. Frounze]

hello,

I've stumbled upon this in some code:

n = !!x;

I've ran it and 'n' is always either 0 or 1. Is '!!' an operator (what's it
called?) and is it standard/portable?

n = !!x;
should be equivalent to:
n = !(!x);
or even:
n = !(!(x));

And n should be 1 if x is nonzero, 0 if x is zero.

Got the idea?

Alex

 

[Mike Wahler]

hello,

I've stumbled upon this in some code:

n = !!x;

I've ran it and 'n' is always either 0 or 1.

Yes, because that's always the result of the ! ("logical not")
operator.

Is '!!' an operator

No, ! is an operator. It's result is always either zero or one.
It is simply being used twice in the above code. E.g.

!0 == 1
!1 == 0
!42 == 0;
!!42 == 1 /* because !42 == 0, then !(!42) == 1
(because !0 == 1) */


etc.

(what's it
called?)

"Logical not".

and is it standard/portable?

Yes.

int i = 42;
int j = !i; /* initializes 'j' with 0 */
int k; = !!i; /* initializes 'k' with 1 */
int m = !j; /* initializes 'm' with 1 */

The typical reason for this 'double application' of the logical
not operator is to transform a nonzero value (which logically
always evaluates to 'true') into a specific 'true' value (in
this case one (1). The reason for needing to do this depends
upon the application. Here's a simple contrived example:

#include <stdio.h>

/* zero value is invalid, any nonzero value is valid */
void validate(int value)
{
static const char *msg[] = {"invalid", "valid"};
printf("value %d is %s\n", msg[!!i]);
/* note that !!0 always is exactly 0 */
}

int main()
{
validate(42);
return 0;
}

IOW, !42 == 0 , !!42 == 1 , !!42 != 42

If some other specific 'true' value were needed, one would
simply perform more arithmetic upon the value one (e.g. add
some value).

-Mike

 

[DevarajA]

bjk of course ha scritto:

hello,

I've stumbled upon this in some code:

n = !!x;

I've ran it and 'n' is always either 0 or 1. Is '!!' an operator (what's it
called?) and is it standard/portable?

It means 'not not x', evaluating to 0 if x is 0 or to 1 if x is not 0.

 

[Mike Wahler]

#include <stdio.h>

/* zero value is invalid, any nonzero value is valid */
void validate(int value)
{
static const char *msg[] = {"invalid", "valid"};
printf("value %d is %s\n", msg[!!i]);

Oops, should be
printf("value %d is %s\n", msg[!!value]);

 

[Cafer =?utf-8?B?xZ5pbcWfZWs=?=]

[...]

No, ! is an operator. It's result is always either zero or one.

^^^^^^^^^^^^

I think, C standarts says something about logical operations resusts;
if the result is false, it's value is 0 (zero). if the result is true,
it's value is non-zero (like -2, -1, 2, 3, ...). So, it must NOT be
one. This difference has seen according to compiler or target
platform.

For example; some compiler's headers provide TRUE and FALSE constants
like that;

#define FALSE 0
#define TRUE !FALSE

// or

#define TRUE (0==0)
#define FALSE !TRUE




[...]

Best Regards.

 

[Cafer =?utf-8?B?xZ5pbcWfZWs=?=]

[...]

No, ! is an operator. It's result is always either zero or one.

^^^^^^^^^^^^

I think, C standarts says something about logical operations resusts;
if the result is false, it's value is 0 (zero). if the result is true,
it's value is non-zero (like -2, -1, 2, 3, ...). So, it must NOT be

^^^^
may

one. This difference has seen according to compiler or target
platform.

For example; some compiler's headers provide TRUE and FALSE constants
like that;

#define FALSE 0
#define TRUE !FALSE

// or

#define TRUE (0==0)
#define FALSE !TRUE




[...]

Best Regards.

 

[Irrwahn Grausewitz]

Correct.

It does.

Correct.

Wrong, see quote below..

Then those implementations are not conforming. Consider:

ISO/IEC 9899:1999 (E)

6.5.3.3p5
The result of the logical negation operator ! is 0 if the value of
its operand compares unequal to 0, 1 if the value of its operand
compares equal to 0. The result has type int. The expression !E is
equivalent to (0==E).

6.5.9p3
The == (equal to) and != (not equal to) operators are analogous to
the relational operators except for their lower precedence. Each of
the operators yields 1 if the specified relation is true and 0 if it
is false. The result has type int. For any pair of operands, exactly
one of the relations is true.

Similar semantics apply to the other logical operators (&& and ||),
and the relational operators (<, >, <=, >=).

Best regards.

 

[Mike Wahler]

[...]

No, ! is an operator. It's result is always either zero or one.

^^^^^^^^^^^^

I think, C standarts says something about logical operations resusts;

Yes.

if the result is false, it's value is 0 (zero). if the result is true,
it's value is non-zero (like -2, -1, 2, 3, ...). So, it must NOT be

^^^^
may

This is not what the C standard states.

Compilers don't dictate the rules (they can sometimes incorrectly implement
them
however). The C standard (ISO 9899) makes the language rules.
...doesn't change the rules.

This means the macro 'TRUE' will *always* yield the *exact*
value of 1. (!0 == 1, always).


Always has exact value of one.

Always has exact value of zero.

-Mike

 

[Keith Thompson]

For example; some compiler's headers provide TRUE and FALSE constants
like that;

#define FALSE 0
#define TRUE !FALSE

// or

#define TRUE (0==0)
#define FALSE !TRUE

If you want to define symbols TRUE and FALSE, just use:

#define TRUE 1
#define FALSE 0

There is no advantage to be gained from using more complex expressions.

See section 9 of the C FAQ.

 

[Flash Gordon]

[...]

No, ! is an operator. It's result is always either zero or one.

^^^^^^^^^^^^

I think, C standarts says something about logical operations resusts;
if the result is false, it's value is 0 (zero). if the result is true,
it's value is non-zero (like -2, -1, 2, 3, ...). So, it must NOT be
one. This difference has seen according to compiler or target
platform.

Incorrect. The result of any logical operator is *always* 0 or 1 and
this is defined by the standard. What probably has you confused is that
any non-zero value will act as true, so all the values you quote will
act as true. However, I repeat, the boolean operators will never return
any value other than 0 or 1 on *any* implementation.

For example; some compiler's headers provide TRUE and FALSE constants
like that;

#define FALSE 0
#define TRUE !FALSE

// or

#define TRUE (0==0)
#define FALSE !TRUE

In both cases you are guaranteed that TRUE == 1.

 

[Charlie Gordon]

If you want to define symbols TRUE and FALSE, just use:

#define TRUE 1
#define FALSE 0

There is no advantage to be gained from using more complex expressions.

See section 9 of the C FAQ.

As a matter of fact, the above definitions could cause bugs because the macro
expansion is not correctly parenthesized. Here is a contorted example:

#define FALSE 0
#define TRUE !FALSE
char c = FALSE["FT"]; // sets c to 'F'
char c = TRUE["FT"]; // sets c to 0 instead of 'T'

 

[Kenneth Brody]

Cafer ÅžimÅŸek wrote: [...]

I think, C standarts says something about logical operations resusts;
if the result is false, it's value is 0 (zero). if the result is true,
it's value is non-zero (like -2, -1, 2, 3, ...). So, it must NOT be
one. This difference has seen according to compiler or target
platform.

Incorrect. The result of any logical operator is *always* 0 or 1 and
this is defined by the standard. What probably has you confused is that
any non-zero value will act as true, so all the values you quote will
act as true. However, I repeat, the boolean operators will never return
any value other than 0 or 1 on *any* implementation.

[...]

Well, any C89 or later, I assume. I've worked on platforms (prior to
1989) where boolean expressions were 0 or -1.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Charlie Gordon]

Cafer ÅzimÅYek wrote: [...]

I think, C standarts says something about logical operations resusts;
if the result is false, it's value is 0 (zero). if the result is true,
it's value is non-zero (like -2, -1, 2, 3, ...). So, it must NOT be
one. This difference has seen according to compiler or target
platform.

Incorrect. The result of any logical operator is *always* 0 or 1 and
this is defined by the standard. What probably has you confused is that
any non-zero value will act as true, so all the values you quote will
act as true. However, I repeat, the boolean operators will never return
any value other than 0 or 1 on *any* implementation.

[...]

Well, any C89 or later, I assume. I've worked on platforms (prior to
1989) where boolean expressions were 0 or -1.

You must have been programming in Basic!

No C implementation ever used -1 as the value of 0==0

One other explanation for this misunderstanding is that you may have been using
1 bit bitfields: it is implementation defined whether these have values 0 and 1
or 0 and -1. As far as I recall, C99 did not change that.

 

[Michael Mair]

Cafer ÅzimÅYek wrote:
[...]

I think, C standarts says something about logical operations resusts;
if the result is false, it's value is 0 (zero). if the result is true,
it's value is non-zero (like -2, -1, 2, 3, ...). So, it must NOT be
one. This difference has seen according to compiler or target
platform.

Incorrect. The result of any logical operator is *always* 0 or 1 and
this is defined by the standard. What probably has you confused is that
any non-zero value will act as true, so all the values you quote will
act as true. However, I repeat, the boolean operators will never return
any value other than 0 or 1 on *any* implementation.

[...]

Well, any C89 or later, I assume. I've worked on platforms (prior to
1989) where boolean expressions were 0 or -1.

You must have been programming in Basic!

No C implementation ever used -1 as the value of 0==0

As an aside:
I recall seeing some platform specific headers which went for the
all-bits-one representation of "true" -- but the C implementations
gave 1 for !!TRUE as well...

One other explanation for this misunderstanding is that you may have been using
1 bit bitfields: it is implementation defined whether these have values 0 and 1
or 0 and -1. As far as I recall, C99 did not change that.

Naive question after having a look at C99, 6.7.2.1:
Does this ambiguity only hold for "int" bitfields or also for
"signed int" bitfields?

Cheers
Michael

 

[Tim Woodall]

As an aside:
I recall seeing some platform specific headers which went for the
all-bits-one representation of "true" -- but the C implementations
gave 1 for !!TRUE as well...

int is_it_seven(int x)
{
return x==7;
}

if(is_it_seven(7) == TRUE)
printf("7 is seven\n");
else
printf("7 is not seven\n");

While I would never write the explicit test for TRUE [1], I would be
horrified at any header that defined TRUE such that this code didn't
behave as expected.

[1] Other peoples coding standards excepted.

Naive question after having a look at C99, 6.7.2.1:
Does this ambiguity only hold for "int" bitfields or also for
"signed int" bitfields?

If you are using sign-magnitude or ones complement encoding then the
possible values of a signed int bitfield will be +0 and -0 or 0 and a
trap representation.

(I hope there isn't something somewhere that says that bitfields must be
twos complement. I can't see it but I'm sure if there is someone here
will be along quickly to correct me. ;-) )

Tim.

 

[Gordon Burditt]

I recall seeing some platform specific headers which went for the

int is_it_seven(int x)
{
return x==7;
}

if(is_it_seven(7) == TRUE)

This, of course, is more correctly written as
if ((is_it_seven(7) == TRUE) == TRUE)
which should be rewritten as:
if (((is_it_seven(7) == TRUE) == TRUE) == TRUE)

printf("7 is seven\n");
else
printf("7 is not seven\n");

While I would never write the explicit test for TRUE [1], I would be
horrified at any header that defined TRUE such that this code didn't
behave as expected.

While in this case there IS a definition of TRUE which will "do as
expected", there may not be in the case of functions other than
is_it_seven, such as the <ctype.h> functions like isalpha() and
ispunct(), which are *NOT* guaranteed to produce only 0 or 1.

Gordon L. Burditt

 

[Keith Thompson]

As an aside:
I recall seeing some platform specific headers which went for the
all-bits-one representation of "true" -- but the C implementations
gave 1 for !!TRUE as well...

int is_it_seven(int x)
{
return x==7;
}

if(is_it_seven(7) == TRUE)
printf("7 is seven\n");
else
printf("7 is not seven\n");

While I would never write the explicit test for TRUE [1], I would be
horrified at any header that defined TRUE such that this code didn't
behave as expected.

[1] Other peoples coding standards excepted.

The way to avoid this problem is to avoid *ever* doing an equality or
inequality comparison against either TRUE or FALSE. It happens that
FALSE can only be 0 (assuming sanity on the part of the author), so
(whatever == FALSE) is probably safe, but it's easier to remember and
follow the more general rule.

Remember that the is*() functions in <ctype.h> are explicitly allowed
to return non-zero values, so even with TRUE defined as 1, the test
(isalpha(c) == TRUE) is broken.

If you're going to define FALSE and TRUE, there's no reason to use
values other than FALSE==0 and TRUE==1. (Note that C99's <stdbool.h>
has false==0 and true==1.) But if you're going to write
if (is_it_seven(7) == TRUE) ...
you might as well write
if (((is_it_seven(7) == TRUE) != FALSE) == TRUE) ...

Or just do it right:
if (is_it_seven(7)) ...

There's no reason why one unnecessary comparison is better than two or
more. There's only one logical place to stop adding comparisons, and
that's before the first one.

The relational operators are defined to yield 0 or 1; if they don't,
the compiler is broken. But code that depends on this, though valid,
is suspicious; it's too easy to change
count += (x == 42);
to
count += (nearly_equal(x, 42));
and miss the fact that nearly_equal can return -1.

[...]

If you are using sign-magnitude or ones complement encoding then the
possible values of a signed int bitfield will be +0 and -0 or 0 and a
trap representation.

(I hope there isn't something somewhere that says that bitfields must be
twos complement. I can't see it but I'm sure if there is someone here
will be along quickly to correct me. ;-) )

No, bit fields aren't required to be two's complement, so there's no
guarantee that a 1-bit signed bit field can hold a value other than 0.
But signed bit fields in general are unlikely to be useful. That's
not to say that they're never useful. If you want a struct member to
be as small as possible and to hold any value in the range -7..+7, a
4-bit signed bit field is the way to do it. But as soon as you try to
store -8, you've lost some portability. (Then again, a restriction to
2's-complement systems may not be a problem.)

 

[Michael Mair]

As an aside:
I recall seeing some platform specific headers which went for the
all-bits-one representation of "true" -- but the C implementations
gave 1 for !!TRUE as well...

int is_it_seven(int x)
{
return x==7;
}

if(is_it_seven(7) == TRUE)
printf("7 is seven\n");
else
printf("7 is not seven\n");

While I would never write the explicit test for TRUE [1], I would be
horrified at any header that defined TRUE such that this code didn't
behave as expected.

[1] Other peoples coding standards excepted.

Sorry, without C99's _Bool and _True, this argument is bogus.
Apart from the possible range of return values one could expect from
is_it_seven() and the possible mismatch with, say isalnum() == TRUE
or strcmp() != TRUE, there is no benefit in that.
IIRC, this "TRUE" was intended for bitwise operations and conveniently
fulfilled !TRUE == FALSE. However, this would not have worked on a
1s complement platform.

If you are using sign-magnitude or ones complement encoding then the
possible values of a signed int bitfield will be +0 and -0 or 0 and a
trap representation.

(I hope there isn't something somewhere that says that bitfields must be
twos complement. I can't see it but I'm sure if there is someone here
will be along quickly to correct me. ;-) )

Sorry, I probably did not phrase it carefully enough.

This was not my question. I am well aware of s-m and 1s complement,
my question more or less is whether it is possible that a signed
int bitfield could be treated as if it was an unsigned int
bitfield?

Here some context; see especially the footnote:

"
6.7.2.1:

4 A bit-field shall have a type that is a qualified or unqualified
version of _Bool, signed int, unsigned int, or some other
implementation-defined type.

Semantics
[...]
8 A member of a structure or union may have any object type other
than a variably modified type.102)
In addition, a member may be declared to consist of a specified
number of bits (including a sign bit, if any). Such a member is
called a bit-field;103) its width is preceded by a colon.
9 A bit-field is interpreted as a signed or unsigned integer type
consisting of the specified number of bits.104) If the value 0 or
1 is stored into a nonzero-width bit-field of type _Bool, the
value of the bit-field shall compare equal to the value stored.
____
104) As specified in 6.7.2 above, if the actual type specifier
used is int or a typedef-name defined as int, then it is
implementation-defined whether the bit-field is signed or unsigned.
"

Cheers
Michael

 

[Tim Woodall]

As an aside:
I recall seeing some platform specific headers which went for the
all-bits-one representation of "true" -- but the C implementations
gave 1 for !!TRUE as well...

int is_it_seven(int x)
{
return x==7;
}

if(is_it_seven(7) == TRUE)
printf("7 is seven\n");
else
printf("7 is not seven\n");

While I would never write the explicit test for TRUE [1], I would be
horrified at any header that defined TRUE such that this code didn't
behave as expected.

[1] Other peoples coding standards excepted.

Sorry, without C99's _Bool and _True, this argument is bogus.
Apart from the possible range of return values one could expect from
is_it_seven() and the possible mismatch with, say isalnum() == TRUE
or strcmp() != TRUE, there is no benefit in that.

I KNOW there is no benefit in that. Thats why I wrote
"While I would never write the explicit test for TRUE"

But I would not pass review any C source that defined FALSE as anything
other than 0 and TRUE as anything other than 1 (or some equivalent
expression)

Infact, assuming I spotted it, I wouldn't accept any code that had a
function commented /* returns TRUE or FALSE */ unless the function
returned only 1 or 0 regardless of whether the macros TRUE and FALSE
were actually defined

IIRC, this "TRUE" was intended for bitwise operations and conveniently
fulfilled !TRUE == FALSE. However, this would not have worked on a
1s complement platform.

I still wouldn't have accepted it. There will have been a better name
for the macro.

Sorry, I probably did not phrase it carefully enough.

This was not my question. I am well aware of s-m and 1s complement,
my question more or less is whether it is possible that a signed
int bitfield could be treated as if it was an unsigned int
bitfield?

No. (IMO) 6.7.2.1

9 A bit-field is interpreted as a signed or unsigned integer type ...

and then footnote 104) paraphrased - if the type specifier is int it is
implementation defined whether the bitfield is signed or unsigned

Which implies to me that signed int -> signed, unsigned int -> unsigned
and int goes to one or the other.

Tim.