"a < b < c" not the same as "(a < b) && (b < c)"?

[Keith Thompson]

Yes, but it's not only that the result is always 0 or 1.
An unsigned int bitfield of length one always holds either
0 or 1. But only _Bool maps any non-zero value to 1 and
only zero values to 0. There are conversions going on
in both cases (of bitfield and _Bool), but the conversion
rules for _Bool are different from those of any other
integer type.

Yes, well, if it weren't unique there wouldn't be much point in having
it.

 

[Mabden]

pemo wrote:

Yes but then what about
0 < 3 < 2
how is that evaluated?

Associativity - what happens when operators have the same precedence.
< = left to right

So, you've got ((0 < 3) < 2)
which resolves to (1 < 2)
1 [true] (as 0 IS less than 3)

Only for relatively small values of zero...

which resolves to 1 (true)

Couldn't TRUE be an arbitrary number in C? Say, 42? I know we've
discussed NULL being something other than zero, or located at zero, and
I wonder if TRUE and FALSE can be anything other than zero and one? Of
course, it would not be so on most machines you are likely to run
across, but it is all about the Standard, not practice, in c.l.c!

Here is a chance for Keith T to reply to a Mabden post with something
useful! ;-)

 

[Flash Gordon]

pemo wrote:

Yes but then what about
0 < 3 < 2
how is that evaluated?

Associativity - what happens when operators have the same precedence.
< = left to right

So, you've got ((0 < 3) < 2)
which resolves to (1 < 2)
1 [true] (as 0 IS less than 3)

Only for relatively small values of zero...

Far to old a joke to be funny.

Couldn't TRUE be an arbitrary number in C? Say, 42?

The C standard defines the result as being 1, therefore you will not get
any other result in C. This has been stated here many times in the past
and will be covered in any basic C text book worth having.

> I know we've
discussed NULL being something other than zero, or located at zero, and
I wonder if TRUE and FALSE can be anything other than zero and one? Of
course, it would not be so on most machines you are likely to run
across, but it is all about the Standard, not practice, in c.l.c!

Any value other than 0 will act as true, but you will only ever obtain
10 or 1 from expressions that yeald a boolean result. Note that not all
standard functions that you might expect to return a boolean result do so.

Here is a chance for Keith T to reply to a Mabden post with something
useful! ;-)

It is very rare for Keith's responses to not be useful. Since he is a
knowledgeable poster trying to goad him is not your best move.

 

[Keith Thompson]

Couldn't TRUE be an arbitrary number in C? Say, 42? I know we've
discussed NULL being something other than zero, or located at zero, and
I wonder if TRUE and FALSE can be anything other than zero and one? Of
course, it would not be so on most machines you are likely to run
across, but it is all about the Standard, not practice, in c.l.c!

Read section 9 of the C FAQ, "Boolean Expressions and Variables".
(It hasn't yet been updated to reflect the changes in C99.)

 

[Keith Thompson]

Any value other than 0 will act as true, but you will only ever obtain
10 or 1 from expressions that yeald a boolean result. Note that not -------
all standard functions that you might expect to return a boolean
result do so.

Presumably that was a typo for "0 or 1".

 

[Flash Gordon]

Presumably that was a typo for "0 or 1".

Oops. Yes.

 

[Mabden]

I was about to disagree. Fortunately, I looked it up first; you can
assign a pointer value directly to a _Bool. Interesting.

What does that mean? Assign the pointer to a _Bool or the value pointed
at to a _Bool? The former seems nonsensical, the later seems obvious
(why _wouldn't_ you be able to assign the value pointed at by a pointer
to a _Bool???)

If you assign the actual pointer isn't it always true except for a NULL
pointer (in case it would ALMOST always be false)?

I don't see what the "revelation" was here...

 

[Netocrat]

What does that mean? Assign the pointer to a _Bool or the value pointed at
to a _Bool? The former seems nonsensical,

It's consistent with pointer usage in conditional expressions.

the later seems obvious (why
_wouldn't_ you be able to assign the value pointed at by a pointer to a
_Bool???)

The assertion referred to the pointer's value, not the pointed-to value.

If you assign the actual pointer isn't it always true except for a NULL
pointer (in case it would ALMOST always be false)?

Which exception(s) did you have in mind?

[...]

 

[Keith Thompson]

What does that mean? Assign the pointer to a _Bool or the value pointed
at to a _Bool? The former seems nonsensical, the later seems obvious
(why _wouldn't_ you be able to assign the value pointed at by a pointer
to a _Bool???)

I meant exactly what I said.

If you assign the actual pointer isn't it always true except for a NULL
pointer (in case it would ALMOST always be false)?

I don't see what the "revelation" was here...

C99 6.5.16.1, "Simple assignment":

One of the following shall hold:
[...]
the left operand has type _Bool and the right is a pointer.
[...]
In _simple assignment_ (=), the value of the right operand is
converted to the type of the assignment expression and replaces
the value stored in the object designated by the left operand.

C99 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.

(Pointer types are scalar types.)

The conversion of pointers to _Bool should probably also be mentioned
in 6.3.2.3.

 

[Tim Rentsch]

[snip]

C99 6.5.16.1, "Simple assignment":

One of the following shall hold:
[...]
the left operand has type _Bool and the right is a pointer.
[...]
In _simple assignment_ (=), the value of the right operand is
converted to the type of the assignment expression and replaces
the value stored in the object designated by the left operand.

C99 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.

(Pointer types are scalar types.)

The conversion of pointers to _Bool should probably also be mentioned
in 6.3.2.3.

That would go against the (implicit?) rule that requirements
in the Standard are stated in only one place. Could be a
footnote, though.

 

[Mabden]

It's consistent with pointer usage in conditional expressions.

But why? What for? Every pointer except (sometimes) NULL will be true.
Am I missing something?
Feel free to not talk in one sentence questions.

The assertion referred to the pointer's value, not the pointed-to

value.

OK, then it is always true?

Which exception(s) did you have in mind?

The case on some hardware where NULL is not a pointer to location zero.
Or a non-zero NULL pointer. I don't know how to say it right to not just
get back another stupid one liner about how I said it wrong. What I mean
is that all pointers have an address in them that is not zero and would
become a "true" value. The only exception might be the all-zero pointer,
which we've decided may be NULL, be may also not be NULL. If you expect
NULL to equate to "false" you will be right 99.99999% of the time,
except on hardware where it is not true. THe hardware, or other hardware
/ software may decide to use zero address for something else and your
code on that combo will expect a non-NULL pointer to always be "true",
but in that case it may not be true as the pointer is all zeroes and
equates to "false".

In a world where NULL is NOT guaranteed to be zeroes, and other pointers
MAY be all zeroes, assigning a pointer to a _Bool is a "random"
operation.

It seems to me. I'm sure I could find something Zen-like to sum this up
if I wasn't late for work.
We'll have to go with: "each state of mind not touching on things, each
step not positioned anywhere."

 

[Keith Thompson]

But why? What for? Every pointer except (sometimes) NULL will be true.
Am I missing something?

Yes. You should read section 5 of the C FAQ, "Null Pointers".

I think I've explained the whole thing sufficiently in another
response in this thread, but I'll try again here.

If you assign a pointer value to an object of type _Bool, the result
will be 1 (true) if the pointer value is non-null, and will be 0
(false) if the pointer value is null. There is no "sometimes".

OK, then it is always true?

No; see above.

The case on some hardware where NULL is not a pointer to location zero.
Or a non-zero NULL pointer. I don't know how to say it right to not just
get back another stupid one liner about how I said it wrong. What I mean
is that all pointers have an address in them that is not zero and would
become a "true" value. The only exception might be the all-zero pointer,
which we've decided may be NULL, be may also not be NULL. If you expect
NULL to equate to "false" you will be right 99.99999% of the time,
except on hardware where it is not true. THe hardware, or other hardware
/ software may decide to use zero address for something else and your
code on that combo will expect a non-NULL pointer to always be "true",
but in that case it may not be true as the pointer is all zeroes and
equates to "false".

In a world where NULL is NOT guaranteed to be zeroes, and other pointers
MAY be all zeroes, assigning a pointer to a _Bool is a "random"
operation.

It's a bit clearer to refer to a "null pointer" rather than a "NULL
pointer". The term "null pointer" is defined in the standard. "NULL"
is a macro that expands to a "null pointer constant" (which is
distinct from a "null pointer").

It doesn't matter whether a null pointer is represented as
all-bits-zero or as something else. The constant 0 in C program
source is a null pointer constant; if converted to a pointer type, the
result is a null pointer. The internal representation of a null
pointer is irrelevant, just as the representation of a floating-point
value 0.0 is irrelevant. Both are likely to be all-bits-zero, but
they aren't required to be.

Again, please read section 5 of the C FAQ. It doesn't discuss _Bool,
but it does explain null pointers very well.

 

[Flash Gordon]

But why? What for? Every pointer except (sometimes) NULL will be true.
Am I missing something?

Yes, you are missing that a null pointer *never* evaluates to true and a
null pointer *always* evaluates to true.

Feel free to not talk in one sentence questions.


OK, then it is always true?


The case on some hardware where NULL is not a pointer to location zero.
Or a non-zero NULL pointer. I don't know how to say it right to not just

In a world where NULL is NOT guaranteed to be zeroes, and other pointers
MAY be all zeroes, assigning a pointer to a _Bool is a "random"
operation.

The representation of pointers is *completely* irrelevant. If the bit
pattern of the null pointer is the same as the bit pattern of the int 1
it will *still* evaluate to false in a boolean context. If a non null
pointer happens to have a bit representation of all bits zero it will
*still* evaluate to true in a boolean context.

The best thing to do is completely forget that pointers even *have* bit
patterns, just treat them as opaque objects.

It seems to me. I'm sure I could find something Zen-like to sum this up
if I wasn't late for work.
We'll have to go with: "each state of mind not touching on things, each
step not positioned anywhere."

Zen is irrelevant to clear black and white problems of fact where there
is an absolute reference. Try reading a C text book such as K&R2 instead
of relying on philosophy and you might actually stand a chance.

 

[Mabden]

Yes, you are missing that a null pointer *never* evaluates to true and a
null pointer *always* evaluates to true.

Well, that helps clear it up. Let me write that down. never = always.
Got it.

just



The representation of pointers is *completely* irrelevant. If the bit
pattern of the null pointer is the same as the bit pattern of the int 1
it will *still* evaluate to false in a boolean context. If a non null
pointer happens to have a bit representation of all bits zero it will
*still* evaluate to true in a boolean context.

The best thing to do is completely forget that pointers even *have* bit
patterns, just treat them as opaque objects.

OK, assume that I have. What do I do with a boolean value of a pointer?
What program needs this device? Why am I turning a things that points
into a thing that is TRUE or FALSE? Is North true? Is East false? Why is
this being done?

And why does it take 3 emails to get this question answered? Did I
stutter the first time???

Zen is irrelevant to clear black and white problems of fact where there
is an absolute reference. Try reading a C text book such as K&R2 instead
of relying on philosophy and you might actually stand a chance.

Zen is never irrelevant; you merely chose to ignore wisdom, and eschew
thought.

Seriously, you don't think that quote describes pointers and NULL
pointers, even a little...? :-(
Are you taking into consideration that the words are from thousands of
years ago, and there may not have been as many computers in common usage
back then?! What about the fact that I only had 10 minutes to answer
your post... You wanted something about an arrow, didn't you? I'll try
to find something about an arrow.

 

[Flash Gordon]

Well, that helps clear it up. Let me write that down. never = always.
Got it.

That was a typo. A non-null pointer always evaluates to true. This is
obvious from the further explanation I gave.

OK, assume that I have. What do I do with a boolean value of a pointer?
What program needs this device? Why am I turning a things that points
into a thing that is TRUE or FALSE? Is North true? Is East false? Why is
this being done?

Because that is how the C language defines it. See
http://www.eskimo.com/~scs/C-faq/q5.3.html which does not mention the
_Bool type but is talking about boolean expressions and pointers.

And why does it take 3 emails to get this question answered? Did I
stutter the first time???

People assumed, obviously erroneously, that you could do some reasoning
given a hint.

Zen is never irrelevant; you merely chose to ignore wisdom, and eschew
thought.

Considering Zen irrelevant to the definition of the C language,
something completely documented, give you no clue as to what I think of
Zen in other respects.

Seriously, you don't think that quote describes pointers and NULL
pointers, even a little...? :-(

That quote is to stimulate thought about the nature of certain aspects
of reality which are not clearly defined.

Are you taking into consideration that the words are from thousands of
years ago, and there may not have been as many computers in common usage
back then?!

I'm fully aware of that.

> What about the fact that I only had 10 minutes to answer
your post... You wanted something about an arrow, didn't you? I'll try
to find something about an arrow.

No, I expect you to continue to make stupid posts. On the other hand, I
want you to actually try reading the relevant documentation such as the
comp.lang.c FAQ and a decent text book.

Use Zen to look at the nature of reality, use books on C to look at the
definition of C.

 

[Mabden]

I just had to leave that in...

Because that is how the C language defines it. See
http://www.eskimo.com/~scs/C-faq/q5.3.html which does not mention the
_Bool type but is talking about boolean expressions and pointers.

Ah. So you are showing me FAQ about something that doesn't actually talk
about the subject at hand, thanks for that. The part of the message the
you conviently snipped to make me look like (more of) an idiot is
reproduced here (the K lines are Keith's and the M are my own):

K> >> I was about to disagree. Fortunately, I looked it up first; you
K> >> can assign a pointer value directly to a _Bool. Interesting.

M> > What does that mean? Assign the pointer to a _Bool or the value
M> > pointed at to a _Bool? The former seems nonsensical,

The rest was snipped, but I think you get my question. I am asking why
people would be recording the TRUE and FALSE values somewhere and using
them somehow (I don't know, saving them to a file or something) - it
didn't make any sense to me.

The standard you linked to just talks about checking whether a pointer
is NULL or not. I was responding to Keith's comment. Again, why would
you assign a pointer address to a _Bool variable, and if you did
wouldn't that result change depending on the hardware / software
platform? You seem to be saying (but don't actually say) that the _Bool
variable will be TRUE for any valid pointer, well no you don't say
valid. You seem to be saying that if the pointer is set to NULL then my
variable, say Bpval, will be false. If my pointer is initialized, then
Bpval will be true. You also say that these values will be consistant
across any Standard C implementation, and it doesn't matter where NULL
is (all zeroes, some special hardware address, a random point in memory,
etc.) AND it doesn't matter if NULL is somewhere other that all-zeros,
but my pointer points to all-zeros.

You don't address the case of a pointer that has not been initialized
yet, and I suppose it might depend on whether it is a global or an
automatic variable. I'm assuming an automatic variable that is a pointer
is init'ed to all-zeros by the compiler, like all the other automatic
variables - what does the Standard say about that?

Side note:
For some reason I seem to prefer "zeroes" with an e when it stands
alone, but "zeros" when it's a compound word like "all-zeros". Hmmm...
new OT topic?...

People assumed, obviously erroneously, that you could do some reasoning
given a hint.

Ah. Yeah. That might be a mistake. I think it is also obvious that
because some people don't like some of my posts they assume I am new at
this. I would find it hard to believe that many experts have dug into
this particular aspect of the C language.

No, I expect you to continue to make stupid posts. On the other hand, I
want you to actually try reading the relevant documentation such as the
comp.lang.c FAQ and a decent text book.

Good assumption. Ah, homework. Doh!

Use Zen to look at the nature of reality, use books on C to look at the
definition of C.

I use various tools at various times for various reasons. I do not
actually have a copy of the Standard, so I rely on the kindness of
strangers in this regard. BTW people, if you are going to tell someone
to read the FAQ, please put a link in your post, every time. Please
don't assume the OP has the link handy on their desktop. I don't me you,
Flash, you did post a link, which I read immediately. Unfortunately, it
was not what we were talking about, but A for effort, esp. since you
think I'm an idiot. Way to go above and beyond.

 

[Flash Gordon]

Ah. So you are showing me FAQ about something that doesn't actually talk
about the subject at hand, thanks for that. The part of the message the

Because it is relevant showing the usage of pointers in a boolean
context, including when you get true and when false.

you conviently snipped to make me look like (more of) an idiot is
reproduced here (the K lines are Keith's and the M are my own):

K> >> I was about to disagree. Fortunately, I looked it up first; you
K> >> can assign a pointer value directly to a _Bool. Interesting.

M> > What does that mean? Assign the pointer to a _Bool or the value
M> > pointed at to a _Bool? The former seems nonsensical,

The rest was snipped, but I think you get my question. I am asking why
people would be recording the TRUE and FALSE values somewhere and using
them somehow (I don't know, saving them to a file or something) - it
didn't make any sense to me.

You were also giving clear indication of not understanding when a
pointer in a boolean context gives true and when false.

The standard you linked to just talks about checking whether a pointer
is NULL or not. I was responding to Keith's comment. Again, why would
you assign a pointer address to a _Bool variable, and if you did
wouldn't that result change depending on the hardware / software
platform?

There reason it talks about whether it is null or not is because that,
and ONLY that determines whether a pointer yeald a true or false in a
boolean context.

> You seem to be saying (but don't actually say) that the _Bool
variable will be TRUE for any valid pointer, well no you don't say
valid. You seem to be saying that if the pointer is set to NULL then my
variable, say Bpval, will be false.

Because, as stated many times, it is whether the pointer is null or not
that matters.

> If my pointer is initialized, then
Bpval will be true. You also say that these values will be consistant
across any Standard C implementation, and it doesn't matter where NULL
is (all zeroes, some special hardware address, a random point in memory,
etc.) AND it doesn't matter if NULL is somewhere other that all-zeros,
but my pointer points to all-zeros.

I stated in one post that it does not matter if the pointer is all bits
zero, only whether it is a null pointer or not.

You don't address the case of a pointer that has not been initialized
yet, and I suppose it might depend on whether it is a global or an
automatic variable. I'm assuming an automatic variable that is a pointer
is init'ed to all-zeros by the compiler, like all the other automatic
variables - what does the Standard say about that?

Reading the value of ANY uninitialised variable is undefined behaviour,
whether that variable is _Bool, char, int, pointer or anything else. So
literally ANYTHING can happen when you read it, whether to assign to a
_Bool or for any other purpose. You've been here long enough to have
seen this stated many times.

Ah. Yeah. That might be a mistake. I think it is also obvious that
because some people don't like some of my posts they assume I am new at
this.

No, most people assume you are terminally stupid or a troll.

> I would find it hard to believe that many experts have dug into
this particular aspect of the C language.

There is no digging involved. All you nead to know is the behaviour of
pointers in a boolean context and you know what happens when they are
assigned to a _Bool, because such an assignment is *obviously* a boolean
context.

Good assumption. Ah, homework. Doh!

So ready a text book.

I use various tools at various times for various reasons. I do not
actually have a copy of the Standard,

So search for a draft, links have been posted here plenty of times. Or
buy it for 18USD.

Or BUY A TEXT BOOK! The bulk of what you are asking will be covered in
ANY decent beginners text book.

> so I rely on the kindness of
strangers in this regard. BTW people, if you are going to tell someone
to read the FAQ, please put a link in your post, every time.

If you can't be bothered to even type "comp.lang.c FAQ" in to a search
engine then why should we bother doing it for you? I have no bookmark to
the FAQ, I don't remember the URL, I get it from Google every time.

> Please
don't assume the OP has the link handy on their desktop. I don't me you,
Flash, you did post a link, which I read immediately. Unfortunately, it
was not what we were talking about,

It was entirely relevant to you questioning of when you would get true
and when false. If you can't understand that even though I explained
*why* it was relevant, then you are obviously incapable of understanding.

> but A for effort, esp. since you
think I'm an idiot. Way to go above and beyond.

Your score is highly negative for effort and achievement. You are either
a troll, or terminally stupid, and my starting to read your posts
again was obviously a mistake.

*PLONK*

 

[Mabden]

Because it is relevant showing the usage of pointers in a boolean
context, including when you get true and when false.

OK, I understand when they are true and false. You keep going back to
that. I am NOT confused about that. I'm not sure what I'm saying that
makes you keep repeating the same statements over and over.

You were also giving clear indication of not understanding when a
pointer in a boolean context gives true and when false.

Well I didn't mean to. The question, as stated about three or four times
above and below, is why would you would write the boolean value to a
variable. I was wondering what the use was to "assign a pointer value
directly to a _Bool". What does one do with this information at a later
time, that wouldn't be better done by examining the actual pointer
itself? What practical reason, I mean, not just as a homework question.

For instance:

_Bool EndOfString (char *p)
{
_Bool bpVal=false;

while (*p != '\0')
bpVal = p++; /* flag if p becomes null?! WTF? */

return bpVal; /* return "the end of the string was once pointed to" flag
*/
}

Note on above: nothing about pointing to null.

There reason it talks about whether it is null or not is because that,
and ONLY that determines whether a pointer yeald a true or false in a
boolean context.

Avoiding the question to lecture about null pointers, again.

Because, as stated many times, it is whether the pointer is null or not
that matters.

And again.

I stated in one post that it does not matter if the pointer is all bits
zero, only whether it is a null pointer or not.

Didn't I just repeat that back to you? I'm trying to say what I
understand you to be saying, in the hopes that you will get that I
understand what you are saying. So stop repeating it over and over.

There is no digging involved. All you nead to know is the behaviour of
pointers in a boolean context and you know what happens when they are
assigned to a _Bool, because such an assignment is *obviously* a boolean
context.

And then what does one DO with the variable? If you want to test the
pointer, you would test the pointer. By assigning to the boolean
variable you get to know that a pointer was once null, but you don't
have the pointer so how does that help? Why would you pass around a
variable that told you that a pointer was once valid and pointing to
something, since the pointer may have been moved by the time you check
the boolean variable?

*PLONK*

Oh good, no more pedantic hyperbole.

 

[Netocrat]

[W]hy would you would write the boolean value [of a pointer] to
a variable[?]

Here's a contrived snippet (not compilable or verified correct):

#include <stdbool.h>

_Bool demofunc(char **argv) /* final member of argv array is NULL */
{
_Bool ret;
char **argp = argv;

/* do something with argp */
...

/* store whether argp ended on final array member */
ret = argp;


/* reset argp and do something else with it */
argp = argv;
...

return ret; /* or otherwise utilise the value of ret */
}

 

[Mabden]

[W]hy would you would write the boolean value [of a pointer] to
a variable[?]

Here's a contrived snippet (not compilable or verified correct):

Thank you for your help.

#include <stdbool.h>

_Bool demofunc(char **argv) /* final member of argv array is NULL */
{
_Bool ret;
char **argp = argv;

/* do something with argp */
...

/* store whether argp ended on final array member */
ret = argp;


/* reset argp and do something else with it */
argp = argv;
...

return ret; /* or otherwise utilise the value of ret */
}

Why? "utilize the value of ret" how? By your own code, argp is now
pointing somewhere else. ret is merely providing the information that a
pointer once pointed to something, without the pointer itself or any tie
to the pointer to say whether it is still pointing to anything, and, if
it is an INVALID, UNITITIALIZED pointer - it's probably still going to
be "true" except on SOME machines or compilers where it may NOT be true.
Sometimes. And global pointer may have differences than automatic
variables (in functions).

Didn't you see my example:

_Bool EndOfString (char *p)
{
_Bool bpVal=false;

while (*p != '\0')
bpVal = p++; /* flag if p becomes null?! WTF? */

return bpVal; /* return "the end of the string was once pointed to" flag
*/
}

I'm not saying code can't be written. I just can't see why anyone would.
Why not pass around the actual pointer.

What value does this actually have in Real Life?!!! Has ANYONE even /
ever done this?? Can you think of ANY reason to do this that wouldn't be
a Bad Idea?!