if (-1) returns true

[Warren Postma]

Hi,

I came across this C code which I wanted to understand etc it looked like
this:
if (-1) etc

You perhaps weren't aware that -1 has been the "value" of true since the
earliest microprocessor days, and even before that? Why? Because in
two's complement math, a 16 bit integer $FFFF (all bits on) is equal to
1. Now do you get it?

Warren

 

[Warren Postma]

I find this a bit weird since false and negative and true and positive seem

more intuitive.

Weird only because you aren't aware of the underlying way in which CPUs
operate. Anthropomorphizing your machine isn't all that helpful in this
case.

CPUs typically can do an operation on an entire register in the same
number of clock cycles as they can do an operation on a single bit. That
being so, even though you can think of True and False being bit-sized
constants in your mind, they are in fact typically compiler-builtin
constants defined to be the values used by your microprocessor.

And since -1 has been the most commonly used "value" for the boolean
True state since the earliest microprocessor days, and even before that,
it makes sense that in both C, and Pascal, and other languages,
including the Commodore 64's BASIC interpreter, and most other
Microsoft-derived BASICs, true is also -1.

In two's complement math, a 16 bit integer $FFFF (all bits on) is equal
to -1. In CPUs with 32 bit registers, the DWORD/Cardinal/Longint value
$FFFFFFFF is also the internal way in which -1 is represented in
twos-complement form.


Regards,

Warren

 

[Ben Pfaff]

You perhaps weren't aware that -1 has been the "value" of true since
the earliest microprocessor days, and even before that?

In C, 1 is the value of true.

7.16 Boolean type and values <stdbool.h>
1 The header <stdbool.h> defines four macros.
2 The macro
bool
expands to _Bool.
3 The remaining three macros are suitable for use in #if
preprocessing directives. They are

true
which expands to the integer constant 1,

 

[Bruce Roberts]

In C, 1 is the value of true.

I've never had a terribly strong grasp of C, but IIRC, C doesn't have an
intrisic type Boolean. In fact I had quite a shock moving from ALGOL type
languages to C, in part, because of this.

 

[Bruce Roberts]

And since -1 has been the most commonly used "value" for the boolean
True state since the earliest microprocessor days, and even before that,
it makes sense that in both C, and Pascal, and other languages,
including the Commodore 64's BASIC interpreter, and most other
Microsoft-derived BASICs, true is also -1.

What is common to you is not to me. First, -1 is a number, not a Boolean
value. Second, -1 is a number, not a binary value. In fact -1 has many
different binary representations. There is True and False in type Boolean.
Why should anyone care or try to depend on how a compiler actually
implements this. Finally, in my admittedly limited experience with
microprocessor assembly languages its much more common to see instructions
like JZ and JNZ than J-1 and JNOT-1.

Original Pascal, BTW, defined True to be > False. A property that holds true
today in any variant of Pascal with which I'm familiar. Original C doesn't
even have a Boolean type and the fact that one can find different values for
True in existing published libraries says to me that there is still debate
in that community over an appropriate value for True.

 

[Michael Mair]

I've never had a terribly strong grasp of C, but IIRC, C doesn't have an
intrisic type Boolean. In fact I had quite a shock moving from ALGOL type
languages to C, in part, because of this.

C99 introduces the type _Bool which can take the values 0 and 1.
If you #include <stdbool.h>, you get bool, false and true.

Apart from that: Even though everything !=0 is considered true,
"A && B" gives you 1 if both A and B are true.


Cheers
Michael

 

[Ben Pfaff]

I've never had a terribly strong grasp of C, but IIRC, C doesn't have an
intrisic type Boolean.

C99 has intrinsic type _Bool, which represents only 0 and 1.

 

[ATM Dude]

In C, 1 is the value of true.

7.16 Boolean type and values <stdbool.h>
1 The header <stdbool.h> defines four macros.
2 The macro
bool
expands to _Bool.
3 The remaining three macros are suitable for use in #if
preprocessing directives. They are

true
which expands to the integer constant 1,

True enough, but any non-null is considered true, if any bits are
set, it is true, all bits must be 0 to be considered false.

 

[ATM Dude]

I've never had a terribly strong grasp of C, but IIRC, C doesn't have an
intrisic type Boolean. In fact I had quite a shock moving from ALGOL type
languages to C, in part, because of this.

I love that about C, you can test any variable as if it were a boolean.

if(somechar){
// Do your thing
}

or

if(somebyte){
// Ditto
}

 

[Christopher Benson-Manica]

(groups trimmed to clc)

True enough, but any non-null is considered true, if any bits are
set, it is true, all bits must be 0 to be considered false.

That's incorrect; an implementation may use any bit pattern internally
to represent a null pointer.

http://www.eskimo.com/~scs/C-faq/q5.13.html

 

[Walter Roberson]

:Original C doesn't
:even have a Boolean type and the fact that one can find different values for
:True in existing published libraries says to me that there is still debate
:in that community over an appropriate value for True.

Not to me. To me it means that an implimenter that wants to
construct a 'True' in C is free to choose from a large number of
values, but must choose *one* of those values. Which of them
doesn't matter. Any non-zero value is "appropriate" for True in C.

What were you expecting, that the implimenters would code
isTrue(value) as

value == -1 || value == -2 || value == -3 || value == -4 ... ||
value == 1 || value == 2 || value == 3 || value == 4 ...

listing all possible values that are considered "true" in C?


:Original Pascal, BTW, defined True to be > False. A property that holds true
:today in any variant of Pascal with which I'm familiar.

You probably aren't aware, then, that the original Pascal's API
for interfacing to libraries defined true as "all bits set".
It usually caused extra work for the compilers, but twas how it was
defined. Comparisons would be made unsigned, but signed moves
(with sign extension) would be used when punting a boolean up to
a wider type.

Pascal may have hid the dirt under the covers, but only for that
limited set of functions that Pascal was usable for. As soon as
you tried to write libraries to impliment Pascal or needed to
interface to something platform dependant, you had to know the details.
I worked on a large device control project that was implimented in
Pascal -- we had to bash all kinds of extensions in to make Pascal
useable for anything other than instructional purposes. [That's why
Wirth went ahead and wrote Modula2 -- because Pascal was not suitable
for real software engineering.]

 

[Martin Harvey (Demon account)]

Original Pascal, BTW, defined True to be > False. A property that holds true
today in any variant of Pascal with which I'm familiar.

In addition, depending on exactly *which* definition of Pascal you
want to be bound by:

True = Succ(False)
Ord(False) = 0

Thinking of C style booleans, It seems to me that a dedicated boolean
type is nice, if only because it stops student programmers doing silly
things like:

if (some_var == TRUE)

or (even worse)

if (some_var == TRUE)
some_other_var = FALSE;
else
some_other_var = TRUE;

A coding style which I consider shows at best a poor appreciation of
the expressiveness of the language, and at worst a flagrant disregard
for the actual rules of the language leading to bugs.

One of the things I prefer about Object Pascal, is that given the
design philosophy, it's possible to write thousands of lines of code
without a single numberic constant.

Having said that, when it comes to device drivers, I'll stick to C

MH.

 

[Bruce Roberts]

C99 has intrinsic type _Bool, which represents only 0 and 1.

Not according to Michael Mair. His post indicates that <stdbool.h> has to be
included. Presumably there is only one <stdbool.h> .

 

[Bruce Roberts]

What were you expecting, that the implimenters would code
isTrue(value) as

value == -1 || value == -2 || value == -3 || value == -4 ... ||

I don't care how implementers implement a fundamental type except as it may
impact resource requirements. Why should I have to care? True is True, False
is False as far as I'm concerned those are the only two values that matter
in type Boolean. If the implementers want to implement the type as a
1024-bit value what difference does it make to me as a programmer? None,
except as previously noted.

True is not -1, 0, or 1. True is a bit pattern. -1 is, as I have previously
pointed out, an ambiguous representation of a bit pattern. Are you talking
about signed 8, 16, 32, 48, 64, or 128 bit integers? Are you talking about
sign-bit, one's complement, or two's complement integers? Perhaps -1 is
actually a floating or fixed point value?

You probably aren't aware, then, that the original Pascal's API
for interfacing to libraries defined true as "all bits set".

What "original Pascal API"?

Pascal may have hid the dirt under the covers, but only for that
limited set of functions that Pascal was usable for. As soon as
you tried to write libraries to impliment Pascal or needed to
interface to something platform dependant, you had to know the details.
I worked on a large device control project that was implimented in
Pascal -- we had to bash all kinds of extensions in to make Pascal
useable for anything other than instructional purposes. [That's why
Wirth went ahead and wrote Modula2 -- because Pascal was not suitable
for real software engineering.]

Wirth wrote Modula2, Borland wrote TurboPascal. I still think TP 1-5 are
perhaps the finest compilers around. Certainly the language (TP) was more
than adequate for any software engineering job doable on machines on which
it ran.

 

[infobahn]

Not according to Michael Mair. His post indicates that <stdbool.h> has to be
included. Presumably there is only one <stdbool.h> .

Read Mr Mair's reply more carefully.

 

[Keith Thompson]

Not according to Michael Mair. His post indicates that <stdbool.h> has to be
included. Presumably there is only one <stdbool.h> .

The type _Bool is intrinsic (_Bool is a reserved word).

Including <stdbool.h> gets you an alias "bool" for the type "_Bool",
and the constants "false" and "true". (It was done this way to avoid
breaking pre-C99 programs that define "bool", "false", and "true"
themselves.)

 

[CBFalconer]

.... snip ...

You probably aren't aware, then, that the original Pascal's API
for interfacing to libraries defined true as "all bits set".
It usually caused extra work for the compilers, but twas how it
was defined. Comparisons would be made unsigned, but signed
moves (with sign extension) would be used when punting a
boolean up to a wider type.

Especially since this is way OT for c.l.c, this gross error needs
correction. Pascal always defined booleans as the enumeration
false, true. Check Jensen & Wirths "Pascal Report and User Manual"
if you don't believe me.

 

[DHOLLINGSWORTH2]

Yeah actually true, false was used by Hardware developers, and then came C.

You'll find that 0000 is false and any positive # of bits set is True. It
was true then, and its true now.

What were you expecting, that the implimenters would code
isTrue(value) as

value == -1 || value == -2 || value == -3 || value == -4 ... ||

I don't care how implementers implement a fundamental type except as it
may
impact resource requirements. Why should I have to care? True is True,
False
is False as far as I'm concerned those are the only two values that matter
in type Boolean. If the implementers want to implement the type as a
1024-bit value what difference does it make to me as a programmer? None,
except as previously noted.

True is not -1, 0, or 1. True is a bit pattern. -1 is, as I have
previously
pointed out, an ambiguous representation of a bit pattern. Are you talking
about signed 8, 16, 32, 48, 64, or 128 bit integers? Are you talking about
sign-bit, one's complement, or two's complement integers? Perhaps -1 is
actually a floating or fixed point value?

You probably aren't aware, then, that the original Pascal's API
for interfacing to libraries defined true as "all bits set".

What "original Pascal API"?

Pascal may have hid the dirt under the covers, but only for that
limited set of functions that Pascal was usable for. As soon as
you tried to write libraries to impliment Pascal or needed to
interface to something platform dependant, you had to know the details.
I worked on a large device control project that was implimented in
Pascal -- we had to bash all kinds of extensions in to make Pascal
useable for anything other than instructional purposes. [That's why
Wirth went ahead and wrote Modula2 -- because Pascal was not suitable
for real software engineering.]

Wirth wrote Modula2, Borland wrote TurboPascal. I still think TP 1-5 are
perhaps the finest compilers around. Certainly the language (TP) was more
than adequate for any software engineering job doable on machines on which
it ran.

 

[Nicholas Ring]

Especially since this is way OT for c.l.c, this gross error needs
correction. Pascal always defined booleans as the enumeration
false, true. Check Jensen & Wirths "Pascal Report and User Manual"
if you don't believe me.

You might also want to check to see what the compiler actually does. The
(D5 Pro UP1) compiler produces two different output depending on the check
of true is being done.

If you have this kind of comparision happening:

if SomeFunction() = true then
begin
end;

then the compiler will test to see if the result from SomeFunction() is
equal to 1 ($[00]01).



However, if you have this kind of comparision happening:

if SomeFunction() then
begin
end;

then the compiler will test to see if the result from SomeFunction() is not
zero!


Cheers,
Nick

 

[Michael Mair]

Nope. It has to be included in order to get "bool", "false" and "true",
respectively; which was what I wanted to indicate. The two sentences
still(*) seem to me not to leave room for other interpretations:

,-
| C99 introduces the type _Bool which can take the values 0 and 1.
| If you #include <stdbool.h>, you get bool, false and true.
`-

Read Mr Mair's reply more carefully.

Thanks -- at least someone understands my ramblings


Cheers
Michael

________
(*) Sometimes I come back and reality did not accommodate itself
in order to fit together with my message; sometimes my language
skills are sufficient to give a wrong enough impression to make
someone correct me.