Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #156765 > unrolled thread

Question About &&

Back to article view | Back to comp.lang.c

Contents

  Question About && "das...@gmail.com" <dashley@gmail.com> - 2020-11-27 16:23 -0800
    Re: Question About && Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-11-28 02:23 +0000
    Re: Question About && Richard Damon <Richard@Damon-Family.org> - 2020-11-27 21:24 -0500
    Re: Question About && "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-11-27 19:39 -0800
      Re: Question About && gazelle@shell.xmission.com (Kenny McCormack) - 2020-11-28 04:48 +0000
        Re: Question About && "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-11-28 00:03 -0800
          Re: Question About && James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-11-28 12:17 -0500
            Re: Question About && "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-11-28 16:10 -0800
            Re: Question About && Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-04 00:06 -0800
              Re: Question About && "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-04 06:39 -0800
                Re: Question About && Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 16:41 -0800
                  Re: Question About && "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-07 07:20 -0800
        Re: Question About && "das...@gmail.com" <dashley@gmail.com> - 2020-11-28 14:37 -0800
          Re: Question About && Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-11-28 14:51 -0800
          Re: Question About && "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-11-28 16:53 -0800
      Re: Question About && James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-11-28 12:25 -0500
        Re: Question About && "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-11-28 16:13 -0800

#156765 — Question About &&

I have a while() loop like this:

while (
                 (i < in_buflen)  /* Still chars left, and short-circuit guard for next clause. */
                 &&
                 (strchr(allowed_subsequent_chars, in_buf[i]))
               )

i is size_t, and the result of strchr() is char *.  I'm using the second condition as a substitute for comparison to NULL.  The test as written makes me nervous.

Here is my question:  if I use "&&" with types of very different sizes, for example:

char c;
char *pc;
if (c && pc) ...

is this functionally equivalent to:

if ((c != '\0') && (pc != NULL)) ...

???

My gut tells me yes, but I'm not sure.  Is there any unexpected behavior if one omits the "!=" tests and uses data types of very different sizes?

Thanks, Dave A.

[toc] | [next] | [standalone]

#156766

"das...@gmail.com" <dashley@gmail.com> writes:

> I have a while() loop like this:
>
> while (
>                  (i < in_buflen)  /* Still chars left, and short-circuit guard for next clause. */
>                  &&
>                  (strchr(allowed_subsequent_chars, in_buf[i]))
>                )
>
> i is size_t, and the result of strchr() is char *.  I'm using the
> second condition as a substitute for comparison to NULL.  The test as
> written makes me nervous.
>
> Here is my question: if I use "&&" with types of very different sizes,
> for example:
>
> char c;
> char *pc;
> if (c && pc) ...
>
> is this functionally equivalent to:
>
> if ((c != '\0') && (pc != NULL)) ...
>
> ???
>
> My gut tells me yes, but I'm not sure.

Your gut is sound.  In fact && is defined in terms of comparing the
operands unequal to zero:

6.5.13 Logical AND operator
Syntax
1   logical-AND-expression:
         inclusive-OR-expression
         logical-AND-expression && inclusive-OR-expression

Constraints
2   Each of the operands shall have scalar type.

Semantics
3   The && operator shall yield 1 if both of its operands compare unequal
    to 0; otherwise, it yields 0. The result has type int.

> Is there any unexpected
> behavior if one omits the "!=" tests and uses data types of very
> different sizes?

The different sizes (or types) don't come into it.  && is not like the
arithmetic operators where the operands are converted to a common type
before the expression is evaluated.  Each operand is treated entirely
separately.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#156767

On 11/27/20 7:23 PM, das...@gmail.com wrote:
> I have a while() loop like this:
> 
> while (
>                  (i < in_buflen)  /* Still chars left, and short-circuit guard for next clause. */
>                  &&
>                  (strchr(allowed_subsequent_chars, in_buf[i]))
>                )
> 
> i is size_t, and the result of strchr() is char *.  I'm using the second condition as a substitute for comparison to NULL.  The test as written makes me nervous.
> 
> Here is my question:  if I use "&&" with types of very different sizes, for example:
> 
> char c;
> char *pc;
> if (c && pc) ...
> 
> is this functionally equivalent to:
> 
> if ((c != '\0') && (pc != NULL)) ...
> 
> ???
> 
> My gut tells me yes, but I'm not sure.  Is there any unexpected behavior if one omits the "!=" tests and uses data types of very different sizes?
> 
> Thanks, Dave A.
> 

&& asks if the values are false or true, false basically being the value
0 and true any other value (for pointers, false in the null pointer, and
true being any non-null pointer)

Thus the implied test will be exactly the same as your explicit test.

The explicit tests may be more explicit, and wordier, which is better is
up to debate.

[toc] | [prev] | [next] | [standalone]

#156768

On 11/27/2020 4:23 PM, das...@gmail.com wrote:
> I have a while() loop like this:
> 
> while (
>                   (i < in_buflen)  /* Still chars left, and short-circuit guard for next clause. */
>                   &&
>                   (strchr(allowed_subsequent_chars, in_buf[i]))
>                 )
> 
> i is size_t, and the result of strchr() is char *.  I'm using the second condition as a substitute for comparison to NULL.  The test as written makes me nervous.
> 
> Here is my question:  if I use "&&" with types of very different sizes, for example:
> 
> char c;
> char *pc;
> if (c && pc) ...
> 
> is this functionally equivalent to:
> 
> if ((c != '\0') && (pc != NULL)) ...

a && b = x

if both a and b are not zero, then x = true

anything else, x = false

[toc] | [prev] | [next] | [standalone]

#156770

In article <rpsgom$1mrs$3@gioia.aioe.org>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
...
>a && b = x

This is a syntax error; this can be corrected by changing it to:

    a && (b = x)

which will return 1 if both a and x are non-zero.  Additionally, it will set
b equal to x.

>if both a and b are not zero, then x = true
>
>anything else, x = false

ITYM:

    x = a*b;

this will set x = 0 if either or both of a and b is/are zero.

-- 
No puppet.
No puppet.
You're a puppet.

[toc] | [prev] | [next] | [standalone]

#156771

On 11/27/2020 8:48 PM, Kenny McCormack wrote:
> In article <rpsgom$1mrs$3@gioia.aioe.org>,
> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> ...
>> a && b = x
> 
> This is a syntax error; this can be corrected by changing it to:

It was meant to be a pseudo-code. Sorry for not explicitly pointing that 
out.

[...]

     int a = 1;
     int b = -1;

     int x = a && b;

[toc] | [prev] | [next] | [standalone]

#156784

On 11/28/20 3:03 AM, Chris M. Thomasson wrote:
> On 11/27/2020 8:48 PM, Kenny McCormack wrote:
>> In article <rpsgom$1mrs$3@gioia.aioe.org>,
>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> ...
>>> a && b = x
>>
>> This is a syntax error; this can be corrected by changing it to:
> 
> It was meant to be a pseudo-code. Sorry for not explicitly pointing that 
> out.

Writing something like that as  psuedo-code is very weird. As a general
rule, pseudo-code is meant to either be similar to one or more existing
computer languages, or to use a formalized sub-set of English. In what
existing language does assignment assign to the right operand? There
might be such a language, but why would you use it as the basis for
pseudocode to be posted on a C newsgroup?

[toc] | [prev] | [next] | [standalone]

#156794

On 11/28/2020 9:17 AM, James Kuyper wrote:
> On 11/28/20 3:03 AM, Chris M. Thomasson wrote:
>> On 11/27/2020 8:48 PM, Kenny McCormack wrote:
>>> In article <rpsgom$1mrs$3@gioia.aioe.org>,
>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> ...
>>>> a && b = x
>>>
>>> This is a syntax error; this can be corrected by changing it to:
>>
>> It was meant to be a pseudo-code. Sorry for not explicitly pointing that
>> out.
> 
> Writing something like that as  psuedo-code is very weird. As a general
> rule, pseudo-code is meant to either be similar to one or more existing
> computer languages, or to use a formalized sub-set of English. In what
> existing language does assignment assign to the right operand? There
> might be such a language, but why would you use it as the basis for
> pseudocode to be posted on a C newsgroup?
> 

I was having a bad hair day! Damn.

[toc] | [prev] | [next] | [standalone]

#156908

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 11/28/20 3:03 AM, Chris M. Thomasson wrote:
>
>> On 11/27/2020 8:48 PM, Kenny McCormack wrote:
>>
>>> In article <rpsgom$1mrs$3@gioia.aioe.org>,
>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> ...
>>>
>>>> a && b = x
>>>
>>> This is a syntax error;  this can be corrected by changing it to:
>>
>> It was meant to be a pseudo-code.  Sorry for not explicitly pointing that
>> out.
>
> Writing something like that as  psuedo-code is very weird. [...]

It doesn't strike me as especially weird.  Nor all that
hard to understand either.

[toc] | [prev] | [next] | [standalone]

#156918

On Friday, December 4, 2020 at 3:07:02 AM UTC-5, Tim Rentsch wrote:
> James Kuyper <james...@alumni.caltech.edu> writes: 
> 
> > On 11/28/20 3:03 AM, Chris M. Thomasson wrote: 
> > 
> >> On 11/27/2020 8:48 PM, Kenny McCormack wrote: 
> >> 
> >>> In article <rpsgom$1mrs$3...@gioia.aioe.org>, 
> >>> Chris M. Thomasson <chris.m.t...@gmail.com> wrote: 
> >>> ... 
> >>> 
> >>>> a && b = x 
> >>> 
> >>> This is a syntax error; this can be corrected by changing it to: 
> >> 
> >> It was meant to be a pseudo-code. Sorry for not explicitly pointing that 
> >> out. 
> >
> > Writing something like that as psuedo-code is very weird. [...] 
> 
> It doesn't strike me as especially weird. Nor all that 
> hard to understand either.

I agree that it's not hard to understand - as syntactically invalid C code. If it weren't inconsistent with the context, I'd have expected the most likely correction to be  a && b == x. If I'd been told in advance that it was meant to be interpreted as pseudocode rather than C code, I would have considered the most likely interpretation to be that it was the equivalent of a && b == x.
One thing I literally cannot do is understand it as x = a && b. I can believe and understand that it was meant to have that meaning, but only as a mistake, not as what is actually conveyed by that notation.

[toc] | [prev] | [next] | [standalone]

#157005

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Friday, December 4, 2020 at 3:07:02 AM UTC-5, Tim Rentsch wrote:
>
>> James Kuyper <james...@alumni.caltech.edu> writes:
>>
>>> On 11/28/20 3:03 AM, Chris M. Thomasson wrote:
>>>
>>>> On 11/27/2020 8:48 PM, Kenny McCormack wrote:
>>>>
>>>>> In article <rpsgom$1mrs$3...@gioia.aioe.org>,
>>>>> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>>>>> ...
>>>>>
>>>>>> a && b = x
>>>>>
>>>>> This is a syntax error;  this can be corrected by changing it to:
>>>>
>>>> It was meant to be a pseudo-code.  Sorry for not explicitly pointing that
>>>> out.
>>>
>>> Writing something like that as psuedo-code is very weird.  [...]
>>
>> It doesn't strike me as especially weird.  Nor all that
>> hard to understand either.
>
> I agree that it's not hard to understand - as syntactically invalid C
> code.  [...]

It being not syntactically valid C helps make it easier to
understand than if that were not the case.  So I consider that
aspect a plus, in that one respect.

> One thing I literally cannot do is understand it as x = a && b.
> [...]

I didn't take it that way.  After seeing that it didn't make
sense as C, I took it to be a kind of mathematical equation.  Of
course, I know the original poster Chris Thomasson to be someone
who isn't always careful with language, so the funny way of
expressing it didn't bother me, and when he later referred to it
as pseudo-code that didn't bother me either.  Barely noticed it,
in fact.

[toc] | [prev] | [next] | [standalone]

#157039

On Sunday, December 6, 2020 at 7:41:36 PM UTC-5, Tim Rentsch wrote:
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes: 
> 
> > On Friday, December 4, 2020 at 3:07:02 AM UTC-5, Tim Rentsch wrote: 
> > 
> >> James Kuyper <james...@alumni.caltech.edu> writes: 
> >> 
> >>> On 11/28/20 3:03 AM, Chris M. Thomasson wrote: 
> >>> 
> >>>> On 11/27/2020 8:48 PM, Kenny McCormack wrote: 
> >>>> 
> >>>>> In article <rpsgom$1mrs$3...@gioia.aioe.org>, 
> >>>>> Chris M. Thomasson <chris.m.t...@gmail.com> wrote: 
> >>>>> ... 
> >>>>> 
> >>>>>> a && b = x 
> >>>>> 
> >>>>> This is a syntax error; this can be corrected by changing it to: 
> >>>> 
> >>>> It was meant to be a pseudo-code. Sorry for not explicitly pointing that 
> >>>> out. 
> >>> 
> >>> Writing something like that as psuedo-code is very weird. [...] 
> >> 
> >> It doesn't strike me as especially weird. Nor all that 
> >> hard to understand either. 
> > 
> > I agree that it's not hard to understand - as syntactically invalid C
> > code. [...] 
> 
> It being not syntactically valid C helps make it easier to 
> understand than if that were not the case. So I consider that 
> aspect a plus, in that one respect.
> > One thing I literally cannot do is understand it as x = a && b.
> > [...] 
> 
> I didn't take it that way. After seeing that it didn't make 
> sense as C, I took it to be a kind of mathematical equation.

In C, a = b specifies assignment, while a == b tests for equality. In mathematics, '=' is almost always used for a purpose that doesn't match either of those meanings. It asserts equality, rather than testing for it, and assignment is almost never explicitly addressed in ordinary mathematics (obvious exception: the subset of mathematics that describes computation). That meaning doesn't fit the context, either.

[toc] | [prev] | [next] | [standalone]

#156791

On Friday, November 27, 2020 at 11:48:33 PM UTC-5, Kenny McCormack wrote:
> In article <rpsgom$1mrs$3...@gioia.aioe.org>,
> Chris M. Thomasson <chris.m.t...@gmail.com> wrote: 
> ... 
> >a && b = x
> This is a syntax error; this can be corrected by changing it to: 
> 
> a && (b = x) 
> 
> which will return 1 if both a and x are non-zero. Additionally, it will set 
> b equal to x.
> >if both a and b are not zero, then x = true 
> > 
> >anything else, x = false
> ITYM: 
> 
> x = a*b; 
> 
> this will set x = 0 if either or both of a and b is/are zero. 

I'm not sure I follow you there.  If a, b, and x are unsigned 32-bit integers (for example), then on most platforms:

a = 65536;
b = 65536;
x = a * b;

will set x to 0.

So, * does not seem functionally equivalent to &&.

I must be missing your intended meaning.

[toc] | [prev] | [next] | [standalone]

#156792

On Saturday, 28 November 2020 at 22:37:54 UTC, das...@gmail.com wrote:
> On Friday, November 27, 2020 at 11:48:33 PM UTC-5, Kenny McCormack wrote: 
> > In article <rpsgom$1mrs$3...@gioia.aioe.org>, 
> > Chris M. Thomasson <chris.m.t...@gmail.com> wrote: 
> > ... 
> > >a && b = x 
> > This is a syntax error; this can be corrected by changing it to: 
> > 
> > a && (b = x) 
> > 
> > which will return 1 if both a and x are non-zero. Additionally, it will set 
> > b equal to x. 
> > >if both a and b are not zero, then x = true 
> > > 
> > >anything else, x = false 
> > ITYM: 
> > 
> > x = a*b; 
> > 
> > this will set x = 0 if either or both of a and b is/are zero.
> I'm not sure I follow you there. If a, b, and x are unsigned 32-bit integers (for example), then on most platforms: 
> 
> a = 65536; 
> b = 65536; 
> x = a * b; 
> 
> will set x to 0. 
> 
> So, * does not seem functionally equivalent to &&. 
> 
> I must be missing your intended meaning.
>
AND is the intersection operation, which is related to multiplication. For instance if half the children
are gitls and 80% of the children have ice creams, we would expect 0.5 * 0.8 = 0.4 or 40% of
children to be girls and have ice creams.

If you regard 0 as "false" and non 0 as "true", then a multiplied by b is similarly "false" or
"true" according to a AND b. However if the numbers overflow, as they can in C,  this no longer 
holds.

[toc] | [prev] | [next] | [standalone]

#156796

On 11/28/2020 2:37 PM, das...@gmail.com wrote:
> On Friday, November 27, 2020 at 11:48:33 PM UTC-5, Kenny McCormack wrote:
>> In article <rpsgom$1mrs$3...@gioia.aioe.org>,
>> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>> ...
>>> a && b = x
>> This is a syntax error; this can be corrected by changing it to:
>>
>> a && (b = x)
>>
>> which will return 1 if both a and x are non-zero. Additionally, it will set
>> b equal to x.
>>> if both a and b are not zero, then x = true
>>>
>>> anything else, x = false
>> ITYM:
>>
>> x = a*b;
>>
>> this will set x = 0 if either or both of a and b is/are zero.
> 
> I'm not sure I follow you there.  If a, b, and x are unsigned 32-bit integers (for example), then on most platforms:
> 
> a = 65536;
> b = 65536;
> x = a * b;
> 
> will set x to 0.
> 
> So, * does not seem functionally equivalent to &&.
> 
> I must be missing your intended meaning.
> 

I failed and caused confusion, sorry. damn. Now, assuming a and b are 
unsigned 32-bit integers, well:

a = 65536;
b = 65536;
x = a && b;

x will be 1 because both a and b are not zero.

[toc] | [prev] | [next] | [standalone]

#156785

On 11/27/20 10:39 PM, Chris M. Thomasson wrote:
...
> a && b = x

Apparently you actually meant

    x = a && b
> 
> if both a and b are not zero, then x = true
> 
> anything else, x = false

You did not specify the types of a and b, and && can be applied to
pointer types, which cannot store values of 0. When you assign a value
of 0 to a pointer, or compare a pointer value with 0, that 0 is
recognized as a null pointer constant, and implicitly converted into a
null pointer of the other pointer's type. All null pointers compare
equal to each other, which is why any null pointer compares equal to 0,
despite not being able to store a 0. That's why the standard uses the
somewhat more complicated phrase "compare unequal to 0" rather than "are
not zero".

[toc] | [prev] | [next] | [standalone]

#156795

On 11/28/2020 9:25 AM, James Kuyper wrote:
> On 11/27/20 10:39 PM, Chris M. Thomasson wrote:
> ...
>> a && b = x
> 
> Apparently you actually meant
> 
>      x = a && b
>>
>> if both a and b are not zero, then x = true
>>
>> anything else, x = false
> 
> You did not specify the types of a and b, and && can be applied to
> pointer types, which cannot store values of 0. When you assign a value
> of 0 to a pointer, or compare a pointer value with 0, that 0 is
> recognized as a null pointer constant, and implicitly converted into a
> null pointer of the other pointer's type. All null pointers compare
> equal to each other, which is why any null pointer compares equal to 0,
> despite not being able to store a 0. That's why the standard uses the
> somewhat more complicated phrase "compare unequal to 0" rather than "are
> not zero".
> 

Indeed. I am sorry for the confusion I caused!

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web