«

In the following C code snippet

int i=2,j=-1,k=-1,z;
x = ++i || ++j && ++k;

here the right side of || is not evaluated because ++i is a non zero
value( || is short circuit evaluating operator)...

But will the value of x be always 1????

________________________________________

On May 13, 8:00*pm, Eric Sosman <Eric.Sos...@sun.com> wrote:
> prasoonthegr...@gmail.com wrote:
> > In the following C code snippet
>
> > int i=2,j=-1,k=-1,z;
> > x = ++i || ++j && ++k;
>
> > here the right side of || is not evaluated because ++i is a non zero
> > value( || is short circuit evaluating operator)...
>
> > But will the value of x be always 1????
>
> * * *Yes, if `x' is a variable of a type that can hold the value `1'.
> If `x' is a `char*' or a `struct tm' or a `union foobar', or a
> `signed int : 1' bit-field, then No.
>
> --
> Eric.Sos...@sun.com

My mistake 'z' was rather 'x'

int i=2,j=-1,k=-1,x;
x = ++i || ++j && ++k;

I mean to say... the value returned by the left sub-expression (++i ||
++j && ++k; ) is true in this case....

Does true always mean '1'????

writes:
> On May 13, 8:00*pm, Eric Sosman <Eric.Sos...@sun.com> wrote:
>> prasoonthegr...@gmail.com wrote:
>> > In the following C code snippet
>>
>> > int i=2,j=-1,k=-1,z;
>> > x = ++i || ++j && ++k;
>>
>> > here the right side of || is not evaluated because ++i is a non zero
>> > value( || is short circuit evaluating operator)...
>>
>> > But will the value of x be always 1????
>>
>> * * *Yes, if `x' is a variable of a type that can hold the value `1'.
>> If `x' is a `char*' or a `struct tm' or a `union foobar', or a
>> `signed int : 1' bit-field, then No.
>
> My mistake 'z' was rather 'x'
>
> int i=2,j=-1,k=-1,x;
> x = ++i || ++j && ++k;
>
> I mean to say... the value returned by the left sub-expression (++i ||
> ++j && ++k; ) is true in this case....
>
> Does true always mean '1'????

Yes and no.

In a conditional context (if, while, do-while, second clause of a for
loop, etc.), any expression that compares equal to 0 is treated as
false, and any expression that compares unequal to 0 (not just 1) is
treated as true. So this:

if (0) puts("0");
if (1) puts("1");
if (2) puts("2");

will print "1" and "2".

But a relational or equality operator (<, >, <=, >=, ==, !=), or a
logical operator (!, &&, ||) always yields either 0 or 1; they will
never yield any non-zero value other than 1.

But be careful about depending in this fact. Things other than
operators can yield boolean results, but those results aren't
necessarily normalized to 0 or 1. For example, the is*() functions
declared in <ctype.h> can return any non-zero value to indicate a true
condition.

You can define your own "false" and "true" symbols as 0 and 1,
respectively (or use the "bool" type in <stdbool.h> if your
implementation supports it), but you should be careful how you use
them. For example, this:

if (condition == true) ...

is dangerous, since condition could be true without being equal to 1.
Instead, just write:

if (condition) ...

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On May 13, 8:44*pm, Eric Sosman <Eric.Sos...@sun.com> wrote:
> prasoonthegr...@gmail.com wrote:
> > [...]
> > Does true always mean '1'????
>
> * * *C's comparison and logical operators always deliver `0'
> for "false" and `1' for "true." *So does the `!' operator.
>
> * * *C's testing constructs -- if(), while(), and so on --
> treat `0' as "false" and any non-zero value (including `1')
> as "true." *A null pointer compares equal to `0' and is
> therefore "false," while a non-null pointer compares unequal
> to `0' and is thus "true" even though it has no numeric value
> at all. *(My personal preference is to write `if (ptr != NULL)'
> rather than `if (ptr)', but not everyone shares my tastes.)

What is the basic significant difference between if(ptr!=NULL) and if
(ptr) (that means if ptr is true)????

> * * *Note that functions like isdigit() are not comparison
> or logical operators; they deliver `0' for "false" but may
> deliver something other than `1' for "true."

prasoonthegr...@gmail.com wrote:
> On May 13, 8:00 pm, Eric Sosman <Eric.Sos...@sun.com> wrote:
> > prasoonthegr...@gmail.com wrote:
> > > In the following C code snippet
> >
> > > int i=2,j=-1,k=-1,z;
> > > x = ++i || ++j && ++k;
> >
> > > here the right side of || is not evaluated because ++i is a non zero
> > > value( || is short circuit evaluating operator)...
> >
> > > But will the value of x be always 1????
> >
> > Yes, if `x' is a variable of a type that can hold the value `1'.
> > If `x' is a `char*' or a `struct tm' or a `union foobar', or a
> > `signed int : 1' bit-field, then No.
> >
> > --
> > Eric.Sos...@sun.com
>
> My mistake 'z' was rather 'x'
>
> int i=2,j=-1,k=-1,x;
> x = ++i || ++j && ++k;
>
> I mean to say... the value returned by the left sub-expression (++i ||
> ++j && ++k; ) is true in this case....

For these particular values of i, j, and k, yes.

If you're asking if there are other values of i, j, and k which would
give z a value of 0, there are. If i==-1, and either j==-1 or k== -1,
then z will be 0.

> Does true always mean '1'????

No, in C true means !=0: that's how the if(), for() and while()
statements treat their conditions, and also how the conditional and
logical operators interpret their operands. Notice that, among other
things, this means that non-null pointers count as 'true'. However,
the comparison operators are defined as returning 1 when the
comparison is true, and the logical operators "!", "||" and "&&" are
defined as returning 1 when the corresponding truth table would have
"T".

On 13 Mag, 17:56, prasoonthegr...@gmail.com wrote:
[...]
> What is the basic significant difference between if(ptr!=NULL) and if
> (ptr) (that means if ptr is true)????

There is no real difference: Any decent compiler would generate the
same
code for the two snippets.
It is a matter of style and readability of the source code.

ciao
Giacomo

On 13 May, 16:56, prasoonthegr...@gmail.com wrote:
> What is the basic significant difference between if(ptr!=NULL) and if
> (ptr) (that means if ptr is true)????

The basic difference is that in order to use (ptr!=NULL) you
need to include some header which defines NULL, for example
<stdio.h>. On the other hand you can always write if (ptr) or
if (ptr != 0) even if your code does not include any of the
standard headers.

--
If there really exist any apostate ex-Randroids, god damn I'd
love to meet them. Apparently, though, it's like a black hole,
i.e., once you go there, you don't come back - ever.
http://www.iidb.org/vbb/showthread.p...78#post2704978

Spiros Bousbouras <> writes:
> On 13 May, 16:56, prasoonthegr...@gmail.com wrote:
>> What is the basic significant difference between if(ptr!=NULL) and if
>> (ptr) (that means if ptr is true)????
>
> The basic difference is that in order to use (ptr!=NULL) you
> need to include some header which defines NULL, for example
> <stdio.h>. On the other hand you can always write if (ptr) or
> if (ptr != 0) even if your code does not include any of the
> standard headers.

Well, that's *a* difference. In a program of any significant
complexity, you'll almost certainly already have a #include for one of
the several standard headers that define NULL. And even if you
didn't, IMHO adding a #include is a trivial price to pay for the added
clarity. (Yes, I find "if (ptr != NULL)" substantially clearer than
"if (ptr)".)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 13 May, 17:33, Keith Thompson <ks...@mib.org> wrote:
> Spiros Bousbouras <spi...@gmail.com> writes:
> > On 13 May, 16:56, prasoonthegr...@gmail.com wrote:
> >> What is the basic significant difference between if(ptr!=NULL) and if
> >> (ptr) (that means if ptr is true)????
>
> > The basic difference is that in order to use (ptr!=NULL) you
> > need to include some header which defines NULL, for example
> > <stdio.h>. On the other hand you can always write if (ptr) or
> > if (ptr != 0) even if your code does not include any of the
> > standard headers.
>
> Well, that's *a* difference. In a program of any significant
> complexity, you'll almost certainly already have a #include for one of
> the several standard headers that define NULL.

I disagree. In a programme of sufficient complexity, you will have
some translation units #including some of the standard headers
but you may have others which do not.

> And even if you
> didn't, IMHO adding a #include is a trivial price to pay for the added
> clarity. (Yes, I find "if (ptr != NULL)" substantially clearer than
> "if (ptr)".)

If you ever need to examine the output of the preprocessor, including
redundant headers is not a trivial price to pay. Your compiler may do
other things too if you include headers which it wouldn't do if you
didn't.

--
Please [...] provide evidence that your brain damage was a
preexisting condition and was not caused by what you suggest.
Erik Naggum

On 13 Mayýs, 18:44, Eric Sosman <Eric.Sos...@sun.com> wrote:
> prasoonthegr...@gmail.com wrote:
> > [...]
> > Does true always mean '1'????
>
> * * *C's comparison and logical operators always deliver `0'
> for "false" and `1' for "true." *So does the `!' operator.
>
> * * *C's testing constructs -- if(), while(), and so on --
> treat `0' as "false" and any non-zero value (including `1')
> as "true." *A null pointer compares equal to `0' and is
> therefore "false," while a non-null pointer compares unequal
> to `0' and is thus "true" even though it has no numeric value
> at all. *(My personal preference is to write `if (ptr != NULL)'
> rather than `if (ptr)', but not everyone shares my tastes.)
>
> * * *Note that functions like isdigit() are not comparison
> or logical operators; they deliver `0' for "false" but may
> deliver something other than `1' for "true."
>
> --
> Eric.Sos...@sun.com

I want to ask a question. Why the standart is so inconsistent at this
point? Some functions yield 1 as true, some of them not. I've always
been curious about that. Thank you.