Consider a macro of the form
/* --- set north=parent,south=child,east=next,west=previous link of node --- */
#define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
((node *)(ptr))->nsew = (node *)(link)
Not important exactly what it does, just the if(xxx)yyy construction.

Now, suppose I want to use it like
if ( xxx ) setlink(a,b,c); else yyy;
Then the compiler warns that the binding of that else yyy; is ambiguous.

I clearly mean
if ( xxx ) {setlink(a,b,c);} else yyy;
but it's cumbersome and inelegant to write it that way again and again.

Likewise, if I try to define the macro with the {}'s (and the trailing ;)
#define setlink(ptr,nsew,link) { if ( checknode(ptr) ) \
((node *)(ptr))->nsew = (node *)(link); }
Then writing setlink(a,b,c); in the code has that extraneous ; which
can then again cause the same kind of confusion. But omitting the ; just
looks wrong and ugly.

So what's a way to define the macro that simultaneously removes
any potential semantic confusion without introducing the necessity of
any unpretty syntax?
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

John Forkosh <forkosh@panix.com> writes:

> Consider a macro of the form
> /* --- set north=parent,south=child,east=next,west=previous link of node --- */
> #define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
> ((node *)(ptr))->nsew = (node *)(link)
> Not important exactly what it does, just the if(xxx)yyy construction.
>
> Now, suppose I want to use it like
> if ( xxx ) setlink(a,b,c); else yyy;
> Then the compiler warns that the binding of that else yyy; is ambiguous.
>
> I clearly mean
> if ( xxx ) {setlink(a,b,c);} else yyy;
> but it's cumbersome and inelegant to write it that way again and again.
>
> Likewise, if I try to define the macro with the {}'s (and the trailing ;)
> #define setlink(ptr,nsew,link) { if ( checknode(ptr) ) \
> ((node *)(ptr))->nsew = (node *)(link); }
> Then writing setlink(a,b,c); in the code has that extraneous ; which
> can then again cause the same kind of confusion. But omitting the ; just
> looks wrong and ugly.
>
> So what's a way to define the macro that simultaneously removes
> any potential semantic confusion without introducing the necessity of
> any unpretty syntax?

There is a conventional idiom for this:

#define setlink(ptr,nsew,link) \
do { \
if ( checknode(ptr) ) \
((node *)(ptr))->nsew = (node *)(link); \
} while (0)

(The {}s are optional in this case.)

--
Ben.

On 20/07/2021 13:15, John Forkosh wrote:
> Consider a macro of the form
> /* --- set north=parent,south=child,east=next,west=previous link of node --- */
> #define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
> ((node *)(ptr))->nsew = (node *)(link)
> Not important exactly what it does, just the if(xxx)yyy construction.
>
> Now, suppose I want to use it like
> if ( xxx ) setlink(a,b,c); else yyy;
> Then the compiler warns that the binding of that else yyy; is ambiguous.
>
> I clearly mean
> if ( xxx ) {setlink(a,b,c);} else yyy;
> but it's cumbersome and inelegant to write it that way again and again.
>
> Likewise, if I try to define the macro with the {}'s (and the trailing ;)
> #define setlink(ptr,nsew,link) { if ( checknode(ptr) ) \
> ((node *)(ptr))->nsew = (node *)(link); }
> Then writing setlink(a,b,c); in the code has that extraneous ; which
> can then again cause the same kind of confusion. But omitting the ; just
> looks wrong and ugly.
>
> So what's a way to define the macro that simultaneously removes
> any potential semantic confusion without introducing the necessity of
> any unpretty syntax?
>

The best solution, when you can, is to use inline (or static inline)
functions instead of macros. They are clearer, nicer to write, and
safer to use.

But if you can't avoid using a macro, wrap the contents in a "do { ... }
while (0)" loop. This will be executed exactly once, but avoids
complicated interactions with calling code with conditionals.

And I recommend you get in the habit of writing :

if (xxx) {
setlink(a, b, c);
} else {
yyy;
}

People vary in their opinions and styles, of course, and there may be
overriding concerns (such as matching existing code). But the use of
brackets and indentation here means there can never be any doubts or
ambiguities, with the structure immediately obvious to any reader and no
concerns about whether the apparent code structure matches the actual
structure seen by the compiler. It is a style used by people who value
code safety and correctness higher than code compactness. (K&R call it
"the one true brace style".)

John Forkosh <forkosh@panix.com> wrote:
> Consider a macro of the form
> /* --- set north=parent,south=child,east=next,west=previous link of node --- */
> #define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
> ((node *)(ptr))->nsew = (node *)(link)
> Not important exactly what it does, just the if(xxx)yyy construction.
>
> Now, suppose I want to use it like
> if ( xxx ) setlink(a,b,c); else yyy;
> Then the compiler warns that the binding of that else yyy; is ambiguous.
>
> I clearly mean
> if ( xxx ) {setlink(a,b,c);} else yyy;
> but it's cumbersome and inelegant to write it that way again and again.
>
> Likewise, if I try to define the macro with the {}'s (and the trailing ;)
> #define setlink(ptr,nsew,link) { if ( checknode(ptr) ) \
> ((node *)(ptr))->nsew = (node *)(link); }
> Then writing setlink(a,b,c); in the code has that extraneous ; which
> can then again cause the same kind of confusion. But omitting the ; just
> looks wrong and ugly.
>
> So what's a way to define the macro that simultaneously removes
> any potential semantic confusion without introducing the necessity of
> any unpretty syntax?

Hmm... I'm thinking that maybe
/* --- set north=parent,south=child,east=next,west=previous link of node --- */
#define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
((node *)(ptr))->nsew = (node *)(link); else
might work. That is, throw in an empty else-clause at the end of the macro
so that the caller's trailing ; when writing setlink(a,b,c); just
gets expanded as ...else ; which should permit the compiler to
unambiguously bind the else's. Will that work without warnings?
And is there any other situation where it might cause a problem?
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> John Forkosh <forkosh@panix.com> writes:
>
>> Consider a macro of the form
>> /* --- set north=parent,south=child,east=next,west=previous link of node --- */
>> #define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
>> ((node *)(ptr))->nsew = (node *)(link)
>> Not important exactly what it does, just the if(xxx)yyy construction.
>>
>> Now, suppose I want to use it like
>> if ( xxx ) setlink(a,b,c); else yyy;
>> Then the compiler warns that the binding of that else yyy; is ambiguous.
>>
>> I clearly mean
>> if ( xxx ) {setlink(a,b,c);} else yyy;
>> but it's cumbersome and inelegant to write it that way again and again.
>>
>> Likewise, if I try to define the macro with the {}'s (and the trailing ;)
>> #define setlink(ptr,nsew,link) { if ( checknode(ptr) ) \
>> ((node *)(ptr))->nsew = (node *)(link); }
>> Then writing setlink(a,b,c); in the code has that extraneous ; which
>> can then again cause the same kind of confusion. But omitting the ; just
>> looks wrong and ugly.
>>
>> So what's a way to define the macro that simultaneously removes
>> any potential semantic confusion without introducing the necessity of
>> any unpretty syntax?
>
> There is a conventional idiom for this:
>
> #define setlink(ptr,nsew,link) \
> do { \
> if ( checknode(ptr) ) \
> ((node *)(ptr))->nsew = (node *)(link); \
> } while (0)
>
> (The {}s are optional in this case.)

Thanks. Okay, I'll try adopting that conventional style.
Looks a bit elaborate to me, but if that's the convention
then I guess I can get comfortable with it.
P.S. Oops, you can ignore my followup to myself -- I wrote that
before your (and David's) replies were posted on my newsreader.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

David Brown <david.brown@hesbynett.no> wrote:
> On 20/07/2021 13:15, John Forkosh wrote:
>> Consider a macro of the form
>> /* --- set north=parent,south=child,east=next,west=previous link of node --- */
>> #define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
>> ((node *)(ptr))->nsew = (node *)(link)
>> Not important exactly what it does, just the if(xxx)yyy construction.
>>
>> Now, suppose I want to use it like
>> if ( xxx ) setlink(a,b,c); else yyy;
>> Then the compiler warns that the binding of that else yyy; is ambiguous.
>>
>> I clearly mean
>> if ( xxx ) {setlink(a,b,c);} else yyy;
>> but it's cumbersome and inelegant to write it that way again and again.
>>
>> Likewise, if I try to define the macro with the {}'s (and the trailing ;)
>> #define setlink(ptr,nsew,link) { if ( checknode(ptr) ) \
>> ((node *)(ptr))->nsew = (node *)(link); }
>> Then writing setlink(a,b,c); in the code has that extraneous ; which
>> can then again cause the same kind of confusion. But omitting the ; just
>> looks wrong and ugly.
>>
>> So what's a way to define the macro that simultaneously removes
>> any potential semantic confusion without introducing the necessity of
>> any unpretty syntax?
>>
>
> The best solution, when you can, is to use inline (or static inline)
> functions instead of macros. They are clearer, nicer to write, and
> safer to use.
>
> But if you can't avoid using a macro, ...

Yeah, I could avoid using a macro without any particular inconvenience,
but it's kind of got the karma of a macro.

> ... wrap the contents in a "do { ... } while (0)" loop.
> This will be executed exactly once, but avoids
> complicated interactions with calling code with conditionals.

Thanks, David. As you're probably seeing now, Ben suggested exactly
the same thing, so I guess that's the established convention,
and I'll try to get used to doing it that way.

> And I recommend you get in the habit of writing :
> if (xxx) {
> setlink(a, b, c);
> } else {
> yyy;
> }
> People vary in their opinions and styles, of course, ...

Yuk! My, but that's ugly. :) For just one statement in the
if-clause and/or else-clause, I typically wouldn't use {}'s at all.
And for just a few statements, I typically write it like
if (xxx) {
setlink(a, b, c);
getlink(d, e, f); }
else {
yyy;
zzz; }
For many statements
if (xxx) {
aaa;
bbb;
...
zzz;
} /* --- end-of-if(xxx) --- */
(and when there are many statements in the if-cluase,
I'd typically avoid an else-clause entirely)

> ... and there may be
> overriding concerns (such as matching existing code). But the use of
> brackets and indentation here means there can never be any doubts or
> ambiguities, with the structure immediately obvious to any reader and no
> concerns about whether the apparent code structure matches the actual
> structure seen by the compiler. It is a style used by people who value
> code safety and correctness higher than code compactness. (K&R call it
> "the one true brace style".)
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On 20/07/2021 14:19, John Forkosh wrote:
> David Brown <david.brown@hesbynett.no> wrote:

>> And I recommend you get in the habit of writing :
>> if (xxx) {
>> setlink(a, b, c);
>> } else {
>> yyy;
>> }
>> People vary in their opinions and styles, of course, ...
>
> Yuk! My, but that's ugly. :) For just one statement in the
> if-clause and/or else-clause, I typically wouldn't use {}'s at all.

Think about when someone else needs to debug your code and wants to
insert print statements or break points.

> And for just a few statements, I typically write it like
> if (xxx) {
> setlink(a, b, c);
> getlink(d, e, f); }
> else {
> yyy;
> zzz; }

> For many statements
> if (xxx) {
> aaa;
> bbb;
> ...
> zzz;
> } /* --- end-of-if(xxx) --- */
> (and when there are many statements in the if-cluase,
> I'd typically avoid an else-clause entirely)

OK, so not only does someone need to keep in mind whether there are 1 or
N statements, there might now be 1, small N, or large N!

Which means that, when developing code and you are adding or removing
statements, you have to keep adding, removing and repositioning braces?

What happens also when you temporarily need to comment out a line; here:

if (cond)
// statement;
else

this becomes invalid syntax. (And when there is no 'else', the following
statement now becomes conditional!)

And here:

if (xxx) {
setlink(a, b, c);
// getlink(d, e, f); }

You now have an unpaired "{".

There are reasons for following guidelines for code layout...

John Forkosh <forkosh@panix.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> John Forkosh <forkosh@panix.com> writes:
>>
>>> Consider a macro of the form
>>> /* --- set north=parent,south=child,east=next,west=previous link of node --- */
>>> #define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
>>> ((node *)(ptr))->nsew = (node *)(link)
>>> Not important exactly what it does, just the if(xxx)yyy construction.
>>>
>>> Now, suppose I want to use it like
>>> if ( xxx ) setlink(a,b,c); else yyy;
>>> Then the compiler warns that the binding of that else yyy; is ambiguous.
>>>
>>> I clearly mean
>>> if ( xxx ) {setlink(a,b,c);} else yyy;
>>> but it's cumbersome and inelegant to write it that way again and again.
>>>
>>> Likewise, if I try to define the macro with the {}'s (and the trailing ;)
>>> #define setlink(ptr,nsew,link) { if ( checknode(ptr) ) \
>>> ((node *)(ptr))->nsew = (node *)(link); }
>>> Then writing setlink(a,b,c); in the code has that extraneous ; which
>>> can then again cause the same kind of confusion. But omitting the ; just
>>> looks wrong and ugly.
>>>
>>> So what's a way to define the macro that simultaneously removes
>>> any potential semantic confusion without introducing the necessity of
>>> any unpretty syntax?
>>
>> There is a conventional idiom for this:
>>
>> #define setlink(ptr,nsew,link) \
>> do { \
>> if ( checknode(ptr) ) \
>> ((node *)(ptr))->nsew = (node *)(link); \
>> } while (0)
>>
>> (The {}s are optional in this case.)
>
> Thanks. Okay, I'll try adopting that conventional style.
> Looks a bit elaborate to me, but if that's the convention
> then I guess I can get comfortable with it.

Most C programmers won't bat an eyelid at it, but I agree it's clumsy.

When the contingent action is actually just an expression, you can avoid
the if (...) altogether like this:

#define setlink(ptr,nsew,link) \
( checknode(ptr) && (((node *)(ptr))->nsew = (node *)(link)) )

so that there are 'else' issues at all.

--
Ben.

On 7/20/2021 4:15 AM, John Forkosh wrote:
>
> So what's a way to define the macro that simultaneously removes
> any potential semantic confusion without introducing the necessity of
> any unpretty syntax?
>

Formally, you can simply make sure that your macro contains a /complete/
`if` statement

#define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
((node *)(ptr))->nsew = (node *)(link); else

This formally solves the original issue, but opens another can of worms
because of that open `else` dangling at the end.

A somewhat better idea is to invert the logic and place the "payload"
into the `else` branch

#define setlink(ptr,nsew,link) if ( !checknode(ptr) ) ; else\
((node *)(ptr))->nsew = (node *)(link)

which is useful at times but still open to exploits.

And, of course, the de-facto standard approach is the `do { ... } while
(0)` trick already mentioned above. Its functionality is based on a
curious property of C syntax, where `do { } while (...)` happens to be
the only form of compound statement that requires a `;` at the end.

--
Best regards,
Andrey Tarasevich

On 20/07/2021 15:19, John Forkosh wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 20/07/2021 13:15, John Forkosh wrote:
>>> Consider a macro of the form
>>> /* --- set north=parent,south=child,east=next,west=previous link of node --- */
>>> #define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
>>> ((node *)(ptr))->nsew = (node *)(link)
>>> Not important exactly what it does, just the if(xxx)yyy construction.
>>>
>>> Now, suppose I want to use it like
>>> if ( xxx ) setlink(a,b,c); else yyy;
>>> Then the compiler warns that the binding of that else yyy; is ambiguous.
>>>
>>> I clearly mean
>>> if ( xxx ) {setlink(a,b,c);} else yyy;
>>> but it's cumbersome and inelegant to write it that way again and again.
>>>
>>> Likewise, if I try to define the macro with the {}'s (and the trailing ;)
>>> #define setlink(ptr,nsew,link) { if ( checknode(ptr) ) \
>>> ((node *)(ptr))->nsew = (node *)(link); }
>>> Then writing setlink(a,b,c); in the code has that extraneous ; which
>>> can then again cause the same kind of confusion. But omitting the ; just
>>> looks wrong and ugly.
>>>
>>> So what's a way to define the macro that simultaneously removes
>>> any potential semantic confusion without introducing the necessity of
>>> any unpretty syntax?
>>>
>>
>> The best solution, when you can, is to use inline (or static inline)
>> functions instead of macros. They are clearer, nicer to write, and
>> safer to use.
>>
>> But if you can't avoid using a macro, ...
>
> Yeah, I could avoid using a macro without any particular inconvenience,
> but it's kind of got the karma of a macro.
>

Macros don't have karma. Function-like macros are occasionally useful,
such as when you need to handle data of different types, or variadic
macros, or where a parameter to the macro can't work as a function
parameter. But if it is reasonably possible, there are many advantages
to static inline functions.

>> ... wrap the contents in a "do { ... } while (0)" loop.
>> This will be executed exactly once, but avoids
>> complicated interactions with calling code with conditionals.
>
> Thanks, David. As you're probably seeing now, Ben suggested exactly
> the same thing, so I guess that's the established convention,
> and I'll try to get used to doing it that way.

It is indeed the convention - it is the simplest way to get what you
want from a macro. (And if you think it is ugly or cumbersome, that's a
reason to prefer inline functions.)

>
>> And I recommend you get in the habit of writing :
>> if (xxx) {
>> setlink(a, b, c);
>> } else {
>> yyy;
>> }
>> People vary in their opinions and styles, of course, ...
>
> Yuk! My, but that's ugly. :) For just one statement in the
> if-clause and/or else-clause, I typically wouldn't use {}'s at all.

Many people would agree with you. And many people (not necessarily the
same people) make mistakes when writing code without brackets, or - more
often - when modifying and maintaining code that is written without the
brackets.

If you want elegant, minimal coding style, pick a different language.
If you want "cool" tight-looking code with bugs or traps for the next
person down the road, write C without style guides and with minimal
brackets, parentheses, etc. Tight coding styles are fine if everyone
involved has long experience with the language, and you are sure of
exactly what is going on at every point (such as no function-like macros
masquerading as functions).

I work with embedded systems that need to /work/. They don't get to
have bugs - bugs can cost a great deal of money, and in some cases are
safety-critical. When you want to make reliable software (in any
language), you greatly restrict the way you write the code. You care
about making the code do what it appears to do, and appear to do what it
does do - you don't care if someone thinks it is ugly. (You care
greatly about legibility, which is a different thing.) And you care
about it being utterly obvious to anyone reading the code, or making
changes to it in the future. You care about finding multiple ways to
minimise the risk of errors - and apply /all/ of them.

So you put in the brackets in an "if" - then if the enclosed statement
that looks like a function call is actually a multiple statement macro,
it still works. You wrap your multiple statement macros in a
do/while(0) loop - then if it is called from an "if" without brackets,
it still works. You use all the static error checkers and style
checkers you can so that you are warned if you've made a mistake here -
and you set your tools to mark it as an error, not just a warning. And
you have a code review so that someone else checks the style too.

Of course, using brackets for conditionals is just a minor aspect of
writing good, clear, safe code. There are many other things, many of
them more important. And there are cases where there can be do doubts
of what is going on, regardless of brackets. I am quite happy with :

if (!p) return 0;

"return" could not possibly be doing anything else here.

My rules about the enclosed statement(s) are (roughly) :

If you have the statement on a newline, indent it. And if there is
indentation, there are /always/ brackets.

If you have an "else", there are brackets. (And if you have brackets,
there are always new lines and indentations. Indents and brackets go
hand in hand.) If there are nested conditionals, there are brackets.

If you call a function, there are brackets. If you have multiple
actions, there are brackets. (Anyone using a comma operator to do
multiple things in one expression gets thrown out of the code review.)

If there is doubt, there are brackets.

> And for just a few statements, I typically write it like
> if (xxx) {
> setlink(a, b, c);
> getlink(d, e, f); }
> else {
> yyy;
> zzz; }

That's a style some people use. I don't like it, but it is better than
no brackets.

> For many statements
> if (xxx) {
> aaa;
> bbb;
> ...
> zzz;
> } /* --- end-of-if(xxx) --- */
> (and when there are many statements in the if-cluase,
> I'd typically avoid an else-clause entirely)

I don't like the inconsistency here. If you feel the need of adding an
"end-of-if" comment, your conditional is too long - split the function
up. Static functions are free. A bigger monitor is also quite
reasonably priced, if that is what it takes to be able to see the code
you are working on.

>
>> ... and there may be
>> overriding concerns (such as matching existing code). But the use of
>> brackets and indentation here means there can never be any doubts or
>> ambiguities, with the structure immediately obvious to any reader and no
>> concerns about whether the apparent code structure matches the actual
>> structure seen by the compiler. It is a style used by people who value
>> code safety and correctness higher than code compactness. (K&R call it
>> "the one true brace style".)

On 20/07/2021 15:40, Bart wrote:
> On 20/07/2021 14:19, John Forkosh wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>
>>> And I recommend you get in the habit of writing :
>>>          if (xxx) {
>>>                  setlink(a, b, c);
>>>          } else {
>>>                  yyy;
>>>          }
>>> People vary in their opinions and styles, of course, ...
>>
>> Yuk! My, but that's ugly. :)  For just one statement in the
>> if-clause and/or else-clause, I typically wouldn't use {}'s at all.
>
> Think about when someone else needs to debug your code and wants to
> insert print statements or break points.
>
>> And for just a few statements, I typically write it like
>>            if (xxx) {
>>              setlink(a, b, c);
>>              getlink(d, e, f); }
>>            else {
>>              yyy;
>>              zzz; }
>
>
>> For many statements
>>            if (xxx) {
>>              aaa;
>>              bbb;
>>              ...
>>              zzz;
>>              } /* --- end-of-if(xxx) --- */
>> (and when there are many statements in the if-cluase,
>> I'd typically avoid an else-clause entirely)
>
> OK, so not only does someone need to keep in mind whether there are 1 or
> N statements, there might now be 1, small N, or large N!
>
> Which means that, when developing code and you are adding or removing
> statements, you have to keep adding, removing and repositioning braces?
>
> What happens also when you temporarily need to comment out a line; here:
>
>   if (cond)
>  //  statement;
>   else
>
> this becomes invalid syntax. (And when there is no 'else', the following
> statement now becomes conditional!)
>
> And here:
>
>             if (xxx) {
>               setlink(a, b, c);
> //              getlink(d, e, f); }
>
>
> You now have an unpaired "{".
>
> There are reasons for following guidelines for code layout...
>

We have disagreed about more than a few things in this group, Bart, but
here you have eloquently described many important points and I fully
agree with you.

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> John Forkosh <forkosh@panix.com> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> John Forkosh <forkosh@panix.com> writes:
>>>
>>>> Consider a macro of the form
>>>> /* --- set north=parent,south=child,east=next,west=previous link of node --- */
>>>> #define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
>>>> ((node *)(ptr))->nsew = (node *)(link)
>>>> Not important exactly what it does, just the if(xxx)yyy construction.
>>>>
>>>> Now, suppose I want to use it like
>>>> if ( xxx ) setlink(a,b,c); else yyy;
>>>> Then the compiler warns that the binding of that else yyy; is ambiguous.
>>>>
>>>> I clearly mean
>>>> if ( xxx ) {setlink(a,b,c);} else yyy;
>>>> but it's cumbersome and inelegant to write it that way again and again.
>>>>
>>>> Likewise, if I try to define the macro with the {}'s (and the trailing ;)
>>>> #define setlink(ptr,nsew,link) { if ( checknode(ptr) ) \
>>>> ((node *)(ptr))->nsew = (node *)(link); }
>>>> Then writing setlink(a,b,c); in the code has that extraneous ; which
>>>> can then again cause the same kind of confusion. But omitting the ; just
>>>> looks wrong and ugly.
>>>>
>>>> So what's a way to define the macro that simultaneously removes
>>>> any potential semantic confusion without introducing the necessity of
>>>> any unpretty syntax?
>>>
>>> There is a conventional idiom for this:
>>>
>>> #define setlink(ptr,nsew,link) \
>>> do { \
>>> if ( checknode(ptr) ) \
>>> ((node *)(ptr))->nsew = (node *)(link); \
>>> } while (0)
>>>
>>> (The {}s are optional in this case.)
>>
>> Thanks. Okay, I'll try adopting that conventional style.
>> Looks a bit elaborate to me, but if that's the convention
>> then I guess I can get comfortable with it.
>
> Most C programmers won't bat an eyelid at it, but I agree it's clumsy.
>
> When the contingent action is actually just an expression, you can avoid
> the if (...) altogether like this:
>
> #define setlink(ptr,nsew,link) \
> ( checknode(ptr) && (((node *)(ptr))->nsew = (node *)(link)) )
>
> so that there are no 'else' issues at all.

Thanks, again, for the alternative solution. I actually like it
a little better since it avoids the klutzy do-while construction
that has no useful purpose and might only confuse the casual reader,
i.e., "What the heck is he doing that for?" But then again, I never
much liked relying that (a&&b) always evaluates a first, immediately
becoming 0 without evaluating b at all if a is itself 0. You never know
exactly what the next C standard might mess around with.
But your suggestion itself suggested the more explicit version
#define setlink(ptr,nsew,link) \
( checknode(ptr)? (((node *)(ptr))->nsew = (node *)(link)) : 0 )
which I think accomplishes the same thing with explicitly visible logic.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On 7/20/2021 6:48 PM, John Forkosh wrote:
>
> Thanks, again, for the alternative solution. I actually like it
> a little better since it avoids the klutzy do-while construction
> that has no useful purpose and might only confuse the casual reader,
> i.e., "What the heck is he doing that for?"
>

Such "casual reader" has no business looking into such implementation
details. The 'do/while(0)' idiom is so classic, well-established and
universally known that anyone qualified enough to be curious about the
innards of your macro will immediately recognize it and understand its
purpose. As for the others... it might actually be a good thing if it
scares them away.

--
Best regards,
Andrey Tarasevich

John Forkosh <forkosh@panix.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
[...]
>> When the contingent action is actually just an expression, you can avoid
>> the if (...) altogether like this:
>>
>> #define setlink(ptr,nsew,link) \
>> ( checknode(ptr) && (((node *)(ptr))->nsew = (node *)(link)) )
>>
>> so that there are no 'else' issues at all.
>
> Thanks, again, for the alternative solution. I actually like it
> a little better since it avoids the klutzy do-while construction
> that has no useful purpose and might only confuse the casual reader,
> i.e., "What the heck is he doing that for?" But then again, I never
> much liked relying that (a&&b) always evaluates a first, immediately
> becoming 0 without evaluating b at all if a is itself 0. You never know
> exactly what the next C standard might mess around with.
> But your suggestion itself suggested the more explicit version
> #define setlink(ptr,nsew,link) \
> ( checknode(ptr)? (((node *)(ptr))->nsew = (node *)(link)) : 0 )
> which I think accomplishes the same thing with explicitly visible logic.

The "do .. while (0)" idiom is very widely know. All C programmers
*should* know about it. If the macro body is intended to be used in at
statement context, that idiom is, as far as I know, the only method that
actually works in all cases. Saying that it "has no useful purpose" is
incorrect.

It's question 10.4 in the comp.lang.c FAQ, http://www.c-faq.com/

If you can make the macro expansion an expression instead, that's good,
but you can't do so in all cases. An if/then can often be rewritten
using the &&, ||, or ?: operator. A loop cannot.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> John Forkosh <forkosh@panix.com> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> [...]
>>> When the contingent action is actually just an expression, you can avoid
>>> the if (...) altogether like this:
>>>
>>> #define setlink(ptr,nsew,link) \
>>> ( checknode(ptr) && (((node *)(ptr))->nsew = (node *)(link)) )
>>>
>>> so that there are no 'else' issues at all.
>>
>> Thanks, again, for the alternative solution. I actually like it
>> a little better since it avoids the klutzy do-while construction
>> that has no useful purpose and might only confuse the casual reader,
>> i.e., "What the heck is he doing that for?" But then again, I never
>> much liked relying that (a&&b) always evaluates a first, immediately
>> becoming 0 without evaluating b at all if a is itself 0. You never know
>> exactly what the next C standard might mess around with.
>> But your suggestion itself suggested the more explicit version
>> #define setlink(ptr,nsew,link) \
>> ( checknode(ptr)? (((node *)(ptr))->nsew = (node *)(link)) : 0 )
>> which I think accomplishes the same thing with explicitly visible logic.
>
> The "do .. while (0)" idiom is very widely know. All C programmers
> *should* know about it. If the macro body is intended to be used in at
> statement context, that idiom is, as far as I know, the only method that
> actually works in all cases. Saying that it "has no useful purpose" is
> incorrect.

I just meant that the semantics of do{xxx;}while(0); is identical
to just xxx; without the decoration.

> It's question 10.4 in the comp.lang.c FAQ, http://www.c-faq.com/
>
> If you can make the macro expansion an expression instead, that's good,
> but you can't do so in all cases. An if/then can often be rewritten
> using the &&, ||, or ?: operator. A loop cannot.
>

--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On 20/07/2021 15:19, John Forkosh wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 20/07/2021 13:15, John Forkosh wrote:
>>> Consider a macro of the form
>>> /* --- set north=parent,south=child,east=next,west=previous link of node --- */
>>> #define setlink(ptr,nsew,link) if ( checknode(ptr) ) \
>>> ((node *)(ptr))->nsew = (node *)(link)
>>> Not important exactly what it does, just the if(xxx)yyy construction.
>>>
>>> Now, suppose I want to use it like
>>> if ( xxx ) setlink(a,b,c); else yyy;
>>> Then the compiler warns that the binding of that else yyy; is ambiguous.
>>>
>>> I clearly mean
>>> if ( xxx ) {setlink(a,b,c);} else yyy;
>>> but it's cumbersome and inelegant to write it that way again and again.
>>>
>>> Likewise, if I try to define the macro with the {}'s (and the trailing ;)
>>> #define setlink(ptr,nsew,link) { if ( checknode(ptr) ) \
>>> ((node *)(ptr))->nsew = (node *)(link); }
>>> Then writing setlink(a,b,c); in the code has that extraneous ; which
>>> can then again cause the same kind of confusion. But omitting the ; just
>>> looks wrong and ugly.
>>>
>>> So what's a way to define the macro that simultaneously removes
>>> any potential semantic confusion without introducing the necessity of
>>> any unpretty syntax?
>>>
>>
>> The best solution, when you can, is to use inline (or static inline)
>> functions instead of macros. They are clearer, nicer to write, and
>> safer to use.
>>
>> But if you can't avoid using a macro, ...
>
> Yeah, I could avoid using a macro without any particular inconvenience,
> but it's kind of got the karma of a macro.
>

Macros don't have karma. Function-like macros are occasionally useful,
such as when you need to handle data of different types, or variadic
macros, or where a parameter to the macro can't work as a function
parameter. But if it is reasonably possible, there are many advantages
to static inline functions.

>> ... wrap the contents in a "do { ... } while (0)" loop.
>> This will be executed exactly once, but avoids
>> complicated interactions with calling code with conditionals.
>
> Thanks, David. As you're probably seeing now, Ben suggested exactly
> the same thing, so I guess that's the established convention,
> and I'll try to get used to doing it that way.

It is indeed the convention - it is the simplest way to get what you
want from a macro. (And if you think it is ugly or cumbersome, that's a
reason to prefer inline functions.)

>
>> And I recommend you get in the habit of writing :
>> if (xxx) {
>> setlink(a, b, c);
>> } else {
>> yyy;
>> }
>> People vary in their opinions and styles, of course, ...
>
> Yuk! My, but that's ugly. :) For just one statement in the
> if-clause and/or else-clause, I typically wouldn't use {}'s at all.

Many people would agree with you. And many people make mistakes when
writing code without brackets, or - more often - when modifying and
maintaining code that is written without the brackets.

If you want elegant, minimal coding style, pick a different language.
If you want "cool" tight-looking code with bugs or traps for the next
person down the road, write C without style guides and with minimal
brackets, parentheses, etc. Tight coding styles are fine if everyone
involved has long experience with the language, and you are sure of
exactly what is going on at every point (such as no function-like macros
masquerading as functions).

I work with embedded systems that need to /work/. They don't get to
have bugs - bugs can cost a great deal of money, and in some cases are
safety-critical. When you want to make reliable software (in any
language), you greatly restrict the way you write the code. You care
about making the code do what it appears to do, and appear to do what it
does do - you don't care if someone thinks it is ugly. (You care
greatly about legibility, which is a different thing.) And you care
about it being utterly obvious to anyone reading the code, or making
changes to it in the future. You care about finding multiple ways to
minimise the risk of errors - and apply /all/ of them.

So you put in the brackets in an "if" - then if the enclosed statement
that looks like a function call is actually a multiple statement macro,
it still works. You wrap your multiple statement macros in a
do/while(0) loop - then if it is called from an "if" without brackets,
it still works. You use all the static error checkers and style
checkers you can so that you are warned if you've made a mistake here -
and you set your tools to mark it as an error, not just a warning. And
you have a code review so that someone else checks the style too.

Of course, using brackets for conditionals is just a minor aspect of
writing good, clear, safe code. There are many other things, many of
them more important. And there are cases where there can be do doubts
of what is going on, regardless of brackets. I am quite happy with :

if (!p) return 0;

"return" could not possibly be doing anything else here.

My rules about the enclosed statement(s) are (roughly) :

If you have the statement on a newline, indent it. And if there is
indentation, there are /always/ brackets.

If you have an "else", there are brackets. (And if you have brackets,
there are always new lines and indentations. Indents and brackets go
hand in hand.) If there are nested conditionals, there are brackets.

If you call a function, there are brackets. If you have multiple
actions, there are brackets. (Anyone using a comma operator to do
multiple things in one expression gets thrown out of the code review.)

If there is doubt, there are brackets.

> And for just a few statements, I typically write it like
> if (xxx) {
> setlink(a, b, c);
> getlink(d, e, f); }
> else {
> yyy;
> zzz; }

That's a style some people use. I don't like it, but it is better than
no brackets. Style is something that people will /never/ agree on - all
I can tell you is what /I/ see working well.

> For many statements
> if (xxx) {
> aaa;
> bbb;
> ...
> zzz;
> } /* --- end-of-if(xxx) --- */
> (and when there are many statements in the if-cluase,
> I'd typically avoid an else-clause entirely)

I don't like the inconsistency here. Pick a style, and stick to it.

If your conditional is so big you thing an "end-of-if" comment helps,
you should seriously consider re-factoring and splitting the function.
Static functions are free. (And decent sized monitors are not very
expensive either.)

>
>> ... and there may be
>> overriding concerns (such as matching existing code). But the use of
>> brackets and indentation here means there can never be any doubts or
>> ambiguities, with the structure immediately obvious to any reader and no
>> concerns about whether the apparent code structure matches the actual
>> structure seen by the compiler. It is a style used by people who value
>> code safety and correctness higher than code compactness. (K&R call it
>> "the one true brace style".)

John Forkosh <forkosh@panix.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> John Forkosh <forkosh@panix.com> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> [...]
>>>> When the contingent action is actually just an expression, you can avoid
>>>> the if (...) altogether like this:
>>>>
>>>> #define setlink(ptr,nsew,link) \
>>>> ( checknode(ptr) && (((node *)(ptr))->nsew = (node *)(link)) )
>>>>
>>>> so that there are no 'else' issues at all.
>>>
>>> Thanks, again, for the alternative solution. I actually like it
>>> a little better since it avoids the klutzy do-while construction
>>> that has no useful purpose and might only confuse the casual reader,
>>> i.e., "What the heck is he doing that for?" But then again, I never
>>> much liked relying that (a&&b) always evaluates a first, immediately
>>> becoming 0 without evaluating b at all if a is itself 0. You never know
>>> exactly what the next C standard might mess around with.
>>> But your suggestion itself suggested the more explicit version
>>> #define setlink(ptr,nsew,link) \
>>> ( checknode(ptr)? (((node *)(ptr))->nsew = (node *)(link)) : 0 )
>>> which I think accomplishes the same thing with explicitly visible logic.
>>
>> The "do .. while (0)" idiom is very widely know. All C programmers
>> *should* know about it. If the macro body is intended to be used in at
>> statement context, that idiom is, as far as I know, the only method that
>> actually works in all cases. Saying that it "has no useful purpose" is
>> incorrect.
>
> I just meant that the semantics of do{xxx;}while(0); is identical
> to just xxx; without the decoration.

By itself, yes, but not in the context of a macro definition (which
omits the trailing semicolon, BTW).

>> It's question 10.4 in the comp.lang.c FAQ, http://www.c-faq.com/
>>
>> If you can make the macro expansion an expression instead, that's good,
>> but you can't do so in all cases. An if/then can often be rewritten
>> using the &&, ||, or ?: operator. A loop cannot.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 7/20/21 9:48 PM, John Forkosh wrote:
....
> i.e., "What the heck is he doing that for?" But then again, I never
> much liked relying that (a&&b) always evaluates a first, immediately
> becoming 0 without evaluating b at all if a is itself 0. You never know
> exactly what the next C standard might mess around with.

That is a pretty fundamental feature of C; it's one of the last features
of C that I would ever expect to see changed. It would break far too
much existing code.

On 7/21/21 12:15 AM, John Forkosh wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> John Forkosh <forkosh@panix.com> writes:
....
>>> Thanks, again, for the alternative solution. I actually like it
>>> a little better since it avoids the klutzy do-while construction
>>> that has no useful purpose and might only confuse the casual reader,
>>> i.e., "What the heck is he doing that for?" ...
....
>> The "do .. while (0)" idiom is very widely know. All C programmers
>> *should* know about it. If the macro body is intended to be used in at
>> statement context, that idiom is, as far as I know, the only method that
>> actually works in all cases. Saying that it "has no useful purpose" is
>> incorrect.
>
> I just meant that the semantics of do{xxx;}while(0); is identical
> to just xxx; without the decoration.

It's not a question of "do{xxx;} while(0);" vs. "xxx;". It's a key point
of the idiom that it's "do{xxx; yyy;} while(0)" vs. "{xxx; yyy;}". A
function-like macro should not include the terminating ";", because it
would result in a syntax error if used in various locations where a
function would be perfectly legal. And the problem that "do {xxx; yyy;}
while()" is designed to avoid isn't a problem unless there's at least
two statements inside the {}.

See the following for a more detailed explanation:

>> It's question 10.4 in the comp.lang.c FAQ, http://www.c-faq.com/

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 7/20/21 9:48 PM, John Forkosh wrote:
> ...
>> i.e., "What the heck is he doing that for?" But then again, I never
>> much liked relying that (a&&b) always evaluates a first, immediately
>> becoming 0 without evaluating b at all if a is itself 0. You never know
>> exactly what the next C standard might mess around with.
>
> That is a pretty fundamental feature of C; it's one of the last features
> of C that I would ever expect to see changed. It would break far too
> much existing code.

I wouldn't be too complacent about that in the future.
And even today I wouldn't be so blithely sure.
For example, && is commutative, i.e., a&&b == b&&a.
So suppose you're compiling with -O3 optimization,
and your program contains something like...
( (very_very_complicated_expression) && (++n>3) )
So maybe the optimizer says to itself, "Hey, I'll
just execute that very simple right-hand-side first,
and if it's false then I don't have to bother evaluating
that very complicated left-hand-side at all. Could save lots
of time." Now maybe that's not supposed to happen,
but it's way too subtle for my liking.

I'd never consider a&&b to mean that a is a guard on b's execution.
It certainly doesn't look like a guard, and I wouldn't
trust interpreting it that way. Clearly very bad practice
and very bad advice, even if it happens to work.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On 21/07/2021 11:10, John Forkosh wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 7/20/21 9:48 PM, John Forkosh wrote:
>> ...
>>> i.e., "What the heck is he doing that for?" But then again, I never
>>> much liked relying that (a&&b) always evaluates a first, immediately
>>> becoming 0 without evaluating b at all if a is itself 0. You never know
>>> exactly what the next C standard might mess around with.
>>
>> That is a pretty fundamental feature of C; it's one of the last features
>> of C that I would ever expect to see changed. It would break far too
>> much existing code.
>
> I wouldn't be too complacent about that in the future.
> And even today I wouldn't be so blithely sure.
> For example, && is commutative, i.e., a&&b == b&&a.
> So suppose you're compiling with -O3 optimization,
> and your program contains something like...
> ( (very_very_complicated_expression) && (++n>3) )
> So maybe the optimizer says to itself, "Hey, I'll
> just execute that very simple right-hand-side first,
> and if it's false then I don't have to bother evaluating
> that very complicated left-hand-side at all. Could save lots
> of time." Now maybe that's not supposed to happen,
> but it's way too subtle for my liking.
>
> I'd never consider a&&b to mean that a is a guard on b's execution.
> It certainly doesn't look like a guard, and I wouldn't
> trust interpreting it that way. Clearly very bad practice
> and very bad advice, even if it happens to work.
>

Try using (!!a) & (!!b). Or just a & b if you know that both a and b
will be 0 or 1.

On 21/07/2021 12:10, John Forkosh wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 7/20/21 9:48 PM, John Forkosh wrote:
>> ...
>>> i.e., "What the heck is he doing that for?" But then again, I never
>>> much liked relying that (a&&b) always evaluates a first, immediately
>>> becoming 0 without evaluating b at all if a is itself 0. You never know
>>> exactly what the next C standard might mess around with.
>>
>> That is a pretty fundamental feature of C; it's one of the last features
>> of C that I would ever expect to see changed. It would break far too
>> much existing code.
>
> I wouldn't be too complacent about that in the future.
> And even today I wouldn't be so blithely sure.

People who know C /can/ be sure about this.

The only situation you need to worry about && not working as
"short-circuit" is if you are dealing with badly broken, buggy, or
partial C compilers. These do exist, but if you have to use one you
need to know the details and there are going to be large numbers of
issues to consider, not just how && works.

(Different languages can have different rules for &&, just as they can
for any operator. One gotcha is that in C++, && works as in C for
standard types or anything that converts to a bool, but loses its
special properties if you use an operator overload &&. Standard
practice is that you should be extraordinarily reluctant to overload the
&& or || operators.)

> For example, && is commutative, i.e., a&&b == b&&a.

No, not in C.

"x = a && b" means:

if (a) {
if (b) {
x = 1;
} else {
x = 0;
}
} else {
x = 0;
}

Compilers are always free to implement these in any way they like, as
long as the results are the same. If the evaluation of "b" has no side
effects, the compiler can swap the order if that gives better code. And
it can use bitwise instructions and, multiplication instructions,
conditional jumps or anything else for the implementation as long as it
keeps the correct behaviour and semantics.

> So suppose you're compiling with -O3 optimization,
> and your program contains something like...
> ( (very_very_complicated_expression) && (++n>3) )
> So maybe the optimizer says to itself, "Hey, I'll
> just execute that very simple right-hand-side first,
> and if it's false then I don't have to bother evaluating
> that very complicated left-hand-side at all. Could save lots
> of time." Now maybe that's not supposed to happen,
> but it's way too subtle for my liking.
>

The compiler can't do that.

Or, to be more accurate, it /can/ do that - but not if the program would
notice. So it cannot skip the complicated expression if there are (or
could be) side-effects. It could do the easy part first if subsequent
code could not be affected by whether "n" is incremented or not.

> I'd never consider a&&b to mean that a is a guard on b's execution.
> It certainly doesn't look like a guard, and I wouldn't
> trust interpreting it that way. Clearly very bad practice
> and very bad advice, even if it happens to work.
>

Using && for guards is idiomatic C - it is common practice. It is
particularly common with pointers.

If you prefer to write your guards with "if", that's fine - write
whatever is clearest. But you need to understand idiomatic coding.

I find it strange that you could be so concerned about the short-circuit
behaviour of &&, and yet be quite happy to rely on exactly the same
feature of ? :

John Forkosh <forkosh@panix.com> writes:

> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 7/20/21 9:48 PM, John Forkosh wrote:
>> ...
>>> i.e., "What the heck is he doing that for?" But then again, I never
>>> much liked relying that (a&&b) always evaluates a first, immediately
>>> becoming 0 without evaluating b at all if a is itself 0. You never know
>>> exactly what the next C standard might mess around with.
>>
>> That is a pretty fundamental feature of C; it's one of the last features
>> of C that I would ever expect to see changed. It would break far too
>> much existing code.
>
> I wouldn't be too complacent about that in the future.

There absolutely zero chance that the semantics of && will change like
that. It is as deliberate a design choice as any in the language.
Neither B nor BCPL had short-circuit logical operators, relying instead
on bitwise & and |, as did early C. && and || were deliberately added
to simplify many common operations:

while (np != 0 && np->data != 0) ...

> And even today I wouldn't be so blithely sure.

I am not "blithely sure", I'm sure for very good reasons!

> For example, && is commutative, i.e., a&&b == b&&a.

&& is not commutative.

<cut>
> I'd never consider a&&b to mean that a is a guard on b's execution.

That is your choice, of course, but that's a big part of what the
operator is for.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Neither B nor BCPL had short-circuit logical operators, relying instead
> on bitwise & and |, as did early C.

Minor correction. B didn't have short-circuit & and | as such, but it
had a weird rule that in conditional contexts like

if (a & b) ...

the operator short-circuited! C rightly ditched this contextual
interpretation in favour of explicitly short-circuiting operators.

--
Ben.

On 7/21/2021 2:02 PM, Ben Bacarisse wrote:
> John Forkosh <forkosh@panix.com> writes:
>
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> On 7/20/21 9:48 PM, John Forkosh wrote:
>>> ...
>>>> i.e., "What the heck is he doing that for?" But then again, I never
>>>> much liked relying that (a&&b) always evaluates a first, immediately
>>>> becoming 0 without evaluating b at all if a is itself 0. You never know
>>>> exactly what the next C standard might mess around with.
>>>
>>> That is a pretty fundamental feature of C; it's one of the last features
>>> of C that I would ever expect to see changed. It would break far too
>>> much existing code.
>>
>> I wouldn't be too complacent about that in the future.
>
> There absolutely zero chance that the semantics of && will change like
> that. It is as deliberate a design choice as any in the language.
> Neither B nor BCPL had short-circuit logical operators, relying instead
> on bitwise & and |, as did early C. && and || were deliberately added
> to simplify many common operations:
>
> while (np != 0 && np->data != 0) ...
>
>> And even today I wouldn't be so blithely sure.
>
> I am not "blithely sure", I'm sure for very good reasons!

Just more explicit for the OP:
- This behaviour is mandated by the standard.
- This behaviour has been a key feature of the operator since the
beginning of time, so if anything is going to change in the C standard,
it's not going to be this part.

>
>> For example, && is commutative, i.e., a&&b == b&&a.
>
> && is not commutative.

Also for the OP:
The *C operator* && is not commutative.
The logical AND operation is, but that's a difference between the C
operator and the logical operation.

>
> <cut>
>> I'd never consider a&&b to mean that a is a guard on b's execution.
>
> That is your choice, of course, but that's a big part of what the
> operator is for.
>