In article <20220410094247.215@kylheku.com>,
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
....
>> How about Fortran? Or Perl?
>>
>> I.e., if you're going to suggest other, unrelated languages, why not go for
>> the sky?
>
>C++ is not an unrelated language; where you have C++, it is very well

Shhhh!!! They'll hear you!

(Whispers conspiratorially) Yes, you know that, and I know that, but they
don't. In fact, this newsgroup has long ago severed its connection to
reality.

In the dogma of this newsgroup, C++ is an entirely unrelated language, that
is as much off-topic here as any other language (other than C, of course).

You know. How they always make their little snide comments about "3 doors
down, past the water cooler, da da da..."

--
The people who tell us to be proud of the white race are the ones who make
us the most embarrassed by it.

In article <precedence-20220410192504@ram.dialup.fu-berlin.de>,
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>Guillaume <message@bottle.org> writes:
>>Le 08/04/2022 14:00, Stefan Ram a crit:
>>>Recently, I wrote:
>>>board & 1 << row * COLS + col
>>If I saw this coming from someone in my team, I would probably fire them. =)
>
> I find it cute when programming witlings write down their
> fantasies of power. =)
>
>

Well put. My initial reaction to that guy was simpler. Was simply "As if
you ever led anything..."

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Seneca

Le 10/04/2022 à 20:25, Stefan Ram a écrit :
> Guillaume <message@bottle.org> writes:
>> Le 08/04/2022 à 14:00, Stefan Ram a écrit :
>>> Recently, I wrote:
>>> board & 1 << row * COLS + col
>> If I saw this coming from someone in my team, I would probably fire them. =)
>
> I find it cute when programming witlings write down their
> fantasies of power. =)

I find it cute when some people get all worked up when they see a post
that is telling them that what they thought was all smart and skilled
was probably not a good idea, and focus on the unimportant humor part
while carefully ignoring the rest. :)

Le 10/04/2022 à 21:34, Ben a écrit :
> Guillaume <message@bottle.org> writes:
>
>> Le 08/04/2022 à 14:00, Stefan Ram a écrit :
>>> Recently, I wrote:
>>> board & 1 << row * COLS + col
>>
>> If I saw this coming from someone in my team, I would probably fire
>> them. =)
>
> Why is this such a common trope? I doubt any country has such poor
> employment protection that anyone could be fired for such a thing so I
> assume it's just a rhetorical device to say "I really care about this
> issue", but surely there are other ways to do that without being so
> Donal^H^H^H^H Alan Sugar about it.

Come on. I thought the smiley would convey the idea that it was
tongue-in-cheek, but apparently not. So yeah for those taking everything
literally, this was just a humorous way of showing a strong disagreement.

>> The readability rule that applies here is, if you need more than a few
>> seconds figuring out what a given statement exactly does, and may have
>> to even open the C standard to make sure, then it's badly
>> written. Rewrite it.
>
> The trouble with this (since I don't think you literally mean "you"
> here) is who is the typical reader? Do you aim for the lowest common
> denominator, or something in the middle? Does is vary by team? If it's
> a C compiler project, might you assume a higher standard of
> comprehension?

Readability, and trying to avoid hard-to-spot errors goes beyond being
skilled and knowing grammars by heart. It's not a matter of being good
or bad. For insance, indentation and whitespace are basically useless in
C, but they help readability quite a bit, even if you are an expert in
the language.

Regarding operator precedence, this is exactly covered by rule 12.1 of
MISRA-C:2012. "Limited dependence should be placed on operator
precedence rules in expressions"
It describes with examples what is what is not compliant.
While a number of MISRA-C rules can look "too much" to many, including
myself, I think that would be a good start here regarding this issue.

And whether you consider those guidelines in general to "aim for the
lowest common denominator" is debatable. The fact one may be convinced
to know better than those guidelines is also highly questionable.

Similar rules can be seen in other similar standards/coding guidelines.
Apparently no one that answered here have ever ahd to deal with any of
those, otherwise what I said would probably sound pretty obvious.

On Monday, April 11, 2022 at 2:56:11 AM UTC-4, Christian Hanné wrote:
> C++ allows defining your own operator-predence priorities since C++17.

12.6p7: "It is not possible to change the precedence, grouping, or number of operands of operators."

Guillaume <message@bottle.org> writes:

> Le 10/04/2022 à 21:34, Ben a écrit :
>> Guillaume <message@bottle.org> writes:
>>
>>> Le 08/04/2022 à 14:00, Stefan Ram a écrit :
>>>> Recently, I wrote:
>>>> board & 1 << row * COLS + col
>>>
>>> If I saw this coming from someone in my team, I would probably fire
>>> them. =)
>> Why is this such a common trope? I doubt any country has such poor
>> employment protection that anyone could be fired for such a thing so I
>> assume it's just a rhetorical device to say "I really care about this
>> issue", but surely there are other ways to do that without being so
>> Donal^H^H^H^H Alan Sugar about it.
>
> Come on. I thought the smiley would convey the idea that it was
> tongue-in-cheek, but apparently not. So yeah for those taking
> everything literally, this was just a humorous way of showing a strong
> disagreement.

OK. My news client turns emoticons into smilies but it does not know
about =) so I missed it. In fact I've never seen =) before.

The way people use happy faces (I think that's what =) is) these days, I
would use ;) to suggest I'm not serious. Otherwise it could mean you'd
fire them and smile all the way to HR with their P45!

>>> The readability rule that applies here is, if you need more than a few
>>> seconds figuring out what a given statement exactly does, and may have
>>> to even open the C standard to make sure, then it's badly
>>> written. Rewrite it.
>> The trouble with this (since I don't think you literally mean "you"
>> here) is who is the typical reader? Do you aim for the lowest common
>> denominator, or something in the middle? Does is vary by team? If it's
>> a C compiler project, might you assume a higher standard of
>> comprehension?
>
> Readability, and trying to avoid hard-to-spot errors goes beyond being
> skilled and knowing grammars by heart. It's not a matter of being good
> or bad. For insance, indentation and whitespace are basically useless
> in C, but they help readability quite a bit, even if you are an expert
> in the language.

Of course. I didn't really want to open up the discussion too wide, so
I was trying to ask only about those elements that related to what the
reader can be expected to know.

> Regarding operator precedence, this is exactly covered by rule 12.1 of
> MISRA-C:2012. "Limited dependence should be placed on operator
> precedence rules in expressions" It describes with examples what is
> what is not compliant. While a number of MISRA-C rules can look "too
> much" to many, including myself, I think that would be a good start
> here regarding this issue.

I shall have to remain in the dark then about what you consider a good
start because the quote "Limited dependence should be placed on operator
precedence rules in expressions" I think MISRA costs money.

> And whether you consider those guidelines in general to "aim for the
> lowest common denominator" is debatable. The fact one may be convinced
> to know better than those guidelines is also highly questionable.

There are other considerations. Sometimes respecting your team's
ability to get it right without a thick tome of guidelines works
better.

> Similar rules can be seen in other similar standards/coding
> guidelines. Apparently no one that answered here have ever ahd to deal
> with any of those, otherwise what I said would probably sound pretty
> obvious.

I have. I hated it. I looked for another job where I was trusted to
write readable code.

--
Ben.

Am 11.04.2022 um 21:12 schrieb james...@alumni.caltech.edu:
> On Monday, April 11, 2022 at 2:56:11 AM UTC-4, Christian Hanné wrote:
>> C++ allows defining your own operator-predence priorities since C++17.
>
> 12.6p7: "It is not possible to change the precedence, grouping, or number of operands of operators."

That's not from the standard.

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> On Monday, April 11, 2022 at 2:56:11 AM UTC-4, Christian Hanné wrote:
>> C++ allows defining your own operator-predence priorities since C++17.
>
> 12.6p7: "It is not possible to change the precedence, grouping, or
> number of operands of operators."

For clarity, if you cite a section of the standard, I suggest mentioning
which edition and/or including the name of the section, in this case
[over.oper]. The sentence you quoted does appear in every edition of
the standard going back to 1998, but the section number varies. (In
C++17 it's 16.5p6.)

--
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 */

Am 12.04.2022 um 19:55 schrieb Keith Thompson:
> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
>> On Monday, April 11, 2022 at 2:56:11 AM UTC-4, Christian Hanné wrote:
>>> C++ allows defining your own operator-predence priorities since C++17.
>>
>> 12.6p7: "It is not possible to change the precedence, grouping, or
>> number of operands of operators."
>
> For clarity, if you cite a section of the standard, I suggest mentioning
> which edition and/or including the name of the section, in this case
> [over.oper]. The sentence you quoted does appear in every edition of
> the standard going back to 1998, but the section number varies. (In
> C++17 it's 16.5p6.)

You're the liar I'm accused to be.
C++17 allows reassigning the operator precedence for certain statements.

In article <t370s8$1ntv$1@gioia.aioe.org>,
Christian Hann <the.hanne@gmail.com> wrote:
>Am 12.04.2022 um 19:55 schrieb Keith Thompson:
>> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
>>> On Monday, April 11, 2022 at 2:56:11 AM UTC-4, Christian Hann wrote:
>>>> C++ allows defining your own operator-predence priorities since C++17.
>>>
>>> 12.6p7: "It is not possible to change the precedence, grouping, or
>>> number of operands of operators."
>>
>> For clarity, if you cite a section of the standard, I suggest mentioning
>> which edition and/or including the name of the section, in this case
>> [over.oper]. The sentence you quoted does appear in every edition of
>> the standard going back to 1998, but the section number varies. (In
>> C++17 it's 16.5p6.)
>
>You're the liar I'm accused to be.
>C++17 allows reassigning the operator precedence for certain statements.

You are probably right. KT is (usually) full of shit, which is why I have
him in my "select file" - his stuff is always entertaining to read.

But you need to give a demo. Show us a small, complete, compilable C++
program, with the command(s) you used to compile it, and show a sample run
(that demonstrates the point you are claiming).

--
Mike Huckabee has yet to consciously uncouple from Josh Duggar.

On 4/13/2022 7:39 PM, Kenny McCormack wrote:
> In article <t370s8$1ntv$1@gioia.aioe.org>,
> Christian Hann <the.hanne@gmail.com> wrote:
>> Am 12.04.2022 um 19:55 schrieb Keith Thompson:
>>> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
>>>> On Monday, April 11, 2022 at 2:56:11 AM UTC-4, Christian Hann wrote:
>>>>> C++ allows defining your own operator-predence priorities since C++17.
>>>>
>>>> 12.6p7: "It is not possible to change the precedence, grouping, or
>>>> number of operands of operators."
>>>
>>> For clarity, if you cite a section of the standard, I suggest mentioning
>>> which edition and/or including the name of the section, in this case
>>> [over.oper]. The sentence you quoted does appear in every edition of
>>> the standard going back to 1998, but the section number varies. (In
>>> C++17 it's 16.5p6.)
>>
>> You're the liar I'm accused to be.
>> C++17 allows reassigning the operator precedence for certain statements.
>
> You are probably right.

No, he is not. The standard is very clear on this point.
I'm surprised of how much feed the troll is getting from this subthread.
Maybe it has to do with being c.l.c. and the C++ standard is less known
in this context.

I just noticed that the e-mail you're responding to was a response by me
to a message on the comp.lang.c++, which accidentally got posted to
comp.lang.c instead.
So that the folks in c.l.c know what happened to this thread, I'm
including them in this message. However, I've set Reply-To: to
comp.lang.c++ only.

I apologize for the delay in my response. My 7-year-old kids have been
on spring break virtually the entire time I've been working on this
response, and it would have taken me a fair amount of time to figure
this out even without that distraction.

On 4/10/22 14:13, Andrey Tarasevich wrote:
> On 4/8/2022 8:46 PM, james...@alumni.caltech.edu wrote:
>> On Friday, April 8, 2022 at 1:10:22 PM UTC-4, Siri Cruise wrote:
>>> In article <t2plh1$6fk$1...@dont-email.me>,
>> ...
>>> For a time I was thinking of Fortran rules where parentheses can
>>> affect order of evaluation. Once I got that clear that
>>> parentheses in C have no effect on generated code.
>>
>> Parentheses don't directly affect order of evaluation. They do,
>> however, do something far more important - they can change which
>> expressions are sub-expressions of other expressions, which has a
>> big effect on the generated code. In `a + b*c`, `b*c` is the right
>> operand of the `+` operator; in `(a + b)*c`, `a+b` is the left operand
>> of the `*` operator.
>>
>> As a result, parentheses do indirectly affect the order of evaluation,
>> since evaluations of sub-expressions are sequenced before evaluation
>> of the expression they are part of. That is not enough to determine
>> the order of evaluation, but it does constrain the order.
>
> This is lazy wording, which makes it incorrect. The "subexpression
> before expression" sequencing you mention does not cover side effects.

I was sloppy with the wording because I've cited the corresponding
clause from the standard several times recently, and have gotten
tired of citing it exactly.

> It only covers value computations. What you are trying to say is what
> the standard formulates as:
>
> 6.5 Expressions
> 1 [...] The value computations of the operands of an operator are
> sequenced before the value computation of the result of the operator.
>
> Note the specific reference to *value computations*. That is the correct
> wording.
>
> You can put as many parentheses in your expression as you want, they
> won't have any effect on sequencing of side effects. ...

You are right about 6.5p1 only directly constraining the sequencing of
value computation. It's not quite as trivial as the fact that it doesn't
mention side-effects - I'll explain the complications below. However, I
was wrong to say that parentheses can effect the sequencing of side
effects because of that clause. They can effect the sequencing of side
effects, but not for that reason.

> ... So no, you cannot
> just claim that parentheses introduce a "sequenced before" ordering
> without explicitly stating that this ordering applies to value
> computations only.
>
> And, once again, whatever ordering your parentheses might introduce,
> they introduce it in an Abstract C Machine. Until you somehow trace/tie
> that ordering to observable behavior, it won't have any connection to
> the behavior of your specific real-life compiler and your specific
> real-life code.

There's three different kinds of observable behavior:

"— Volatile accesses to objects are evaluated strictly according to the
rules of the abstract machine.
— At program termination, all data written into files shall be identical
to the result that execution of the program according to the abstract
semantics would have produced.
— The input and output dynamics of interactive devices shall take place
as specified in 7.21.3." (5.1.2.3p6)

Virtually any change to the code that can change the behavior of the
abstract machine can trivially be turned into observable behavior by
inserting volatile accesses, writes to files, or input/output to
interactive devices in appropriate locations. I'll be using calls to
putchar() and printf() for that purpose down below.

There's three fundamental kinds of side effects: "Accessing a volatile
object, modifying an object, modifying a file ...". There's one derived
kind of side effect: "calling a function that does any of those
operations." (5.1.2.3p2).

I'm going to ignore volatile accesses, since "What constitutes an access
to an object that has volatile-qualified type is
implementation-defined." (6.7.3), making it impossible to produce an
example that's portably guaranteed to demonstrate my point. Also, while
"volatile accesses" are officially "observable behavior" as far as the
standard is concerned, they do not necessarily constitute "behavior
which can be observed" on any particular system.

What I was thinking of was the fact that "The presence of a sequence
point between the evaluation of expressions A and B implies that every
value computation and side effect associated with A is sequenced before
every value computation and side effect associated with B." (5.1.2.3p3).

Therefore, anything that changes the sequencing of two value
computations will also change the sequencing of their corresponding
side-effects, so long as there's a sequence point between them (either
before or after the change).

However, I didn't think that through. Every single construct that
introduces a sequence point between two expressions also mandates the
sequence of those two expressions, and usually requires that an
expression that is textually to the left of the operator within same
full-expression be sequenced before an expression that is textually on
the right in that same full-expression. Inserting parentheses won't
change that textual order. Sequence points do not generally come between
a sub-expression and evaluation of the expression itself. Finally, most
of the expressions that have associated sequence points don't cause
side-effects.

However, parentheses can still change the sequencing requirements,
because they change which expressions are sub-expressions of other
expressions. As a result, they can change which expressions are
sequenced by any given sequence point.

For example, if all of the following are true:
1. E1, E2, E3, and E4 are expressions that might have side-effects

2. OP1 and OP3 are operators with associated sequence point

3. OP2 is an operator with no associated sequence point

4. The following expressions, which differ only in the placement of
parenthesis:
A: (E1 OP1 E2) OP2 (E3 OP3 E4
B: E1 OP1 (E2 OP2 E3) OP3 E4
are syntactically valid, with no constraint violation or undefined behavior

Then expression A and expression B impose different sequencing
requirements on the side-effects of those expressions:

Expression A: E1 must be evaluated before E2, E3 must be evaluated
before E4.
Expression B: E1 must be evaluated first, E4 must be evaluated last.

Neither expression imposes any other requirements on the sequencing of
side effects. As a result, the order E3 E4 E1 E2 is allowed by
expression A, but not by expression B.

Specific example:

A: ( putchar('a') && putchar('b') ) & ( putchar('c') && putchar('d') );
B: putchar('a') && ( putchar('b') & putchar('c') ) && putchar('d');

"bdac" is a possible output from expression A, but not from expression B.

In that example, changing parentheses merely changed sequenced
expressions into unsequenced expressions (or vice-versa). I'd hoped I
could find an example that reversed the required sequence of two
side-effects, but that turns out to be more difficult. However, there is
one (and only one) exception to several of the generalizations I made up
above:
1. Function calls are the only kinds of expressions where one of the
sequence points associated with function calls does separate a
side effects of a sub-expression from the side effects of the main
expression.
2. Function calls are the only kinds of expressions that have a sequence
point that directly constrains the sequencing of code that is not part
of the same full expression, namely the code in the function body.
3. Function calls are the only kinds of expressions that have an
associated sequence point and can qualify as side effects.

Therefore, I can reverse the sequencing using parentheses in the
following example.

#include <stdio.h>
// pointer to a generic function type used as return type.
typedef void gfunc(void);
// The actual type of the functions below.
typedef gfunc* (afunc)(void);

afunc *strange;
static gfunc* up(void) {
printf("up:strange %s up\n", strange == up ? "==" : "!=");
// Note that this cast is absolutely essential. Attempting to declare a
// function that returns a pointer to a function with that function's
// own type results in infinite recursion.
return (gfunc*)up;
}
Click here to read the complete article

I apologize for the delay in my response. My 7-year-old kids have been
on spring break virtually the entire time I've been working on this
response, and it would have taken me a fair amount of time to figure
this out even without that distraction.

On 4/10/22 14:13, Andrey Tarasevich wrote:
> On 4/8/2022 8:46 PM, james...@alumni.caltech.edu wrote:
>> On Friday, April 8, 2022 at 1:10:22 PM UTC-4, Siri Cruise wrote:
>>> In article <t2plh1$6fk$1...@dont-email.me>,
>> ...
>>> For a time I was thinking of Fortran rules where parentheses can
>>> affect order of evaluation. Once I got that clear that
>>> parentheses in C have no effect on generated code.
>>
>> Parentheses don't directly affect order of evaluation. They do,
>> however, do something far more important - they can change which
>> expressions are sub-expressions of other expressions, which has a
>> big effect on the generated code. In `a + b*c`, `b*c` is the right
>> operand of the `+` operator; in `(a + b)*c`, `a+b` is the left operand
>> of the `*` operator.
>>
>> As a result, parentheses do indirectly affect the order of evaluation,
>> since evaluations of sub-expressions are sequenced before evaluation
>> of the expression they are part of. That is not enough to determine
>> the order of evaluation, but it does constrain the order.
>
> This is lazy wording, which makes it incorrect. The "subexpression
> before expression" sequencing you mention does not cover side effects.

I was sloppy with the wording because I've cited the corresponding
clause from the standard several times recently, and have gotten
tired of citing it exactly.

> It only covers value computations. What you are trying to say is what
> the standard formulates as:
>
> 6.5 Expressions
> 1 [...] The value computations of the operands of an operator are
> sequenced before the value computation of the result of the operator.
>
> Note the specific reference to *value computations*. That is the
> correct wording.
>
> You can put as many parentheses in your expression as you want, they
> won't have any effect on sequencing of side effects. ...

You are right about 6.5p1 only directly constraining the sequencing of
value computation. It's not quite as trivial as the fact that it doesn't
mention side-effects - I'll explain the complications below. However, I
was wrong to say that parentheses can effect the sequencing of side
effects because of that clause. They can effect the sequencing of side
effects, but not for that reason.

> ... So no, you cannot just claim that parentheses introduce a
> "sequenced before" ordering without explicitly stating that this
> ordering applies to value computations only.
>
> And, once again, whatever ordering your parentheses might introduce,
> they introduce it in an Abstract C Machine. Until you somehow
> trace/tie that ordering to observable behavior, it won't have any
> connection to the behavior of your specific real-life compiler and
> your specific real-life code.

There's three different kinds of observable behavior:

"— Volatile accesses to objects are evaluated strictly according to the
rules of the abstract machine.
— At program termination, all data written into files shall be identical
to the result that execution of the program according to the abstract
semantics would have produced.
— The input and output dynamics of interactive devices shall take place
as specified in 7.21.3." (5.1.2.3p6)

Virtually any change to the code that can change the behavior of the
abstract machine can trivially be turned into observable behavior by
inserting volatile accesses, writes to files, or input/output to
interactive devices in appropriate locations. I'll be using calls to
putchar() and printf() for that purpose down below.

There's three fundamental kinds of side effects: "Accessing a volatile
object, modifying an object, modifying a file ...". There's one derived
kind of side effect: "calling a function that does any of those
operations." (5.1.2.3p2).

I'm going to ignore volatile accesses, since "What constitutes an access
to an object that has volatile-qualified type is
implementation-defined." (6.7.3), making it impossible to produce an
example that's portably guaranteed to demonstrate my point. Also, while
"volatile accesses" are officially "observable behavior" as far as the
standard is concerned, they do not necessarily constitute "behavior
which can be observed" on any particular system.

What I was thinking of was the fact that "The presence of a sequence
point between the evaluation of expressions A and B implies that every
value computation and side effect associated with A is sequenced before
every value computation and side effect associated with B." (5.1.2.3p3).

Therefore, anything that changes the sequencing of two value
computations will also change the sequencing of their corresponding
side-effects, so long as there's a sequence point between them (either
before or after the change).

However, I didn't think that through. Every single construct that
introduces a sequence point between two expressions also mandates the
sequence of those two expressions, and usually requires that an
expression that is textually to the left of the operator within same
full-expression be sequenced before an expression that is textually on
the right in that same full-expression. Inserting parentheses won't
change that textual order. Sequence points do not generally come between
a sub-expression and evaluation of the expression itself. Finally, most
of the expressions that have associated sequence points don't cause
side-effects.

However, parentheses can still change the sequencing requirements,
because they change which expressions are sub-expressions of other
expressions. As a result, they can change which expressions are
sequenced by any given sequence point.

For example, if all of the following are true:
1. E1, E2, E3, and E4 are expressions that might have side-effects

2. OP1 and OP3 are operators with associated sequence point

3. OP2 is an operator with no associated sequence point

4. The following expressions, which differ only in the placement of
parenthesis:
A: (E1 OP1 E2) OP2 (E3 OP3 E4
B: E1 OP1 (E2 OP2 E3) OP3 E4
are syntactically valid, with no constraint violation or undefined behavior

Then expression A and expression B impose different sequencing
requirements on the side-effects of those expressions:

Expression A: E1 must be evaluated before E2, E3 must be evaluated
before E4.
Expression B: E1 must be evaluated first, E4 must be evaluated last.

Neither expression imposes any other requirements on the sequencing of
side effects. As a result, the order E3 E4 E1 E2 is allowed by
expression A, but not by expression B.

Specific example:

A: ( putchar('a') && putchar('b') ) & ( putchar('c') && putchar('d') );
B: putchar('a') && ( putchar('b') & putchar('c') ) && putchar('d');

"bdac" is a possible output from expression A, but not from expression B.

In that example, changing parentheses merely changed sequenced
expressions into unsequenced expressions (or vice-versa). I'd hoped I
could find an example that reversed the required sequence of two
side-effects, but that turns out to be more difficult. However, there is
one (and only one) exception to several of the generalizations I made up
above:
1. Function calls are the only kinds of expressions where one of the
sequence points associated with function calls does separate a
side effects of a sub-expression from the side effects of the main
expression.
2. Function calls are the only kinds of expressions that have a sequence
point that directly constrains the sequencing of code that is not part
of the same full expression, namely the code in the function body.
3. Function calls are the only kinds of expressions that have an
associated sequence point and can qualify as side effects.

Therefore, I can reverse the sequencing using parentheses in the
following example.

#include <stdio.h>
// pointer to a generic function type used as return type.
typedef void gfunc(void);
// The actual type of the functions below.
typedef gfunc* (afunc)(void);

afunc *strange;
static gfunc* up(void) {
printf("up:strange %s up\n", strange == up ? "==" : "!=");
// Note that this cast is absolutely essential. Attempting to declare a
// function that returns a pointer to a function with that function's
// own type results in infinite recursion.
return (gfunc*)up;
} static gfunc* down(void) {
printf("down:strange %s down\n", strange == down ? "==" : "!=");
return (gfunc*)down;
} afunc *strange = up;

int main(void)
{ strange = (afunc*)down(); // 1
printf("main:strange %s down\n", strange == down ? "==" : "!=");

On 13/04/2022 20:02, Manfred wrote:
> On 4/13/2022 7:39 PM, Kenny McCormack wrote:
>> In article <t370s8$1ntv$1@gioia.aioe.org>,
>> Christian Hann  <the.hanne@gmail.com> wrote:
>>> Am 12.04.2022 um 19:55 schrieb Keith Thompson:
>>>> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
>>>>> On Monday, April 11, 2022 at 2:56:11 AM UTC-4, Christian Hann wrote:
>>>>>> C++ allows defining your own operator-predence priorities since
>>>>>> C++17.
>>>>>
>>>>> 12.6p7: "It is not possible to change the precedence, grouping, or
>>>>> number of operands of operators."
>>>>
>>>> For clarity, if you cite a section of the standard, I suggest
>>>> mentioning
>>>> which edition and/or including the name of the section, in this case
>>>> [over.oper].  The sentence you quoted does appear in every edition of
>>>> the standard going back to 1998, but the section number varies.  (In
>>>> C++17 it's 16.5p6.)
>>>
>>> You're the liar I'm accused to be.
>>> C++17 allows reassigning the operator precedence for certain statements.
>>
>> You are probably right.
>
> No, he is not. The standard is very clear on this point.
> I'm surprised of how much feed the troll is getting from this subthread.
> Maybe it has to do with being c.l.c. and the C++ standard is less known
> in this context.

Some of Hanné's trolling is subtle enough that some people might be
fooled by it, so it is helpful to correct it. Unfortunately, that has
the side-effect of encouraging him.

On 11/04/2022 15:27, Stefan Ram wrote:
> C is a language with some subtleties, and programming often
> is somewhat complex overall. If you don't trust a C programmer
> to even get an expression as simple as "a & b << c + 1",
> how is he supposed to get more subtle things right?
>

A programmer should spend their time and effort learning the /important/
things - not the frivolities of how to write expressions that are
difficult to read. Details of the presidencies of rarely-used operators
are irrelevant in most coding. Any effort spent learning these details
is wasted. Any code written that relies on such knowledge is wasted
effort by the programmer, and more wasted effort by the reader. The
programmer is supposed to get the subtle things right precisely because
he or she isn't trying to show off their pointless knowledge of this
kind of thing. I want programmers that are smart, not smart-arse.

Guillaume and Vir are right (in my opinion). If someone in the
programming team writes an expression like the one above, it's an
opportunity for learning and to teach the newbie good coding practices.
If the guilty party is not a newbie, it's time for them to re-learn how
to program as part of a team. If they won't re-learn, it's time to
question if they should be part of the team at all.

On 11/04/2022 22:27, Ben wrote:
> Guillaume <message@bottle.org> writes:
>

>> Regarding operator precedence, this is exactly covered by rule 12.1 of
>> MISRA-C:2012. "Limited dependence should be placed on operator
>> precedence rules in expressions" It describes with examples what is
>> what is not compliant. While a number of MISRA-C rules can look "too
>> much" to many, including myself, I think that would be a good start
>> here regarding this issue.
>
> I shall have to remain in the dark then about what you consider a good
> start because the quote "Limited dependence should be placed on operator
> precedence rules in expressions" I think MISRA costs money.
>

Last time I bought a MISRA standard, it was £10, and the pdf I got had
my name watermarked on every page. This has always seemed an incredibly
silly price - companies that need to use MISRA would pay even a hundred
times as much (though they'd be annoyed about it) because they have no
choice. Having a price at all means the document has to be purchased -
and the bureaucracy of purchase orders, bill approval and all the rest
will generally cost a company far more than the £10 price.

One complication with discussions like these is that they are generally
taken out of context. In different types of coding, different
expressions or code patterns turn up. Familiarity is a big factor in
reading or writing correct code, and heavily influences appropriate
guidelines for a particular type of work.

Another complication that has been mentioned is the target audience.
Are they the kind of C programmer that has read and re-read the C
standards? Are they programmers who have had extensive training in
dedicated C course? Are they hardware engineers, mathematicians, or
others with strong technical skills and education, but only a smattering
of C knowledge? Are they coming from other programming languages? Are
they people who are not yet born, who will be looking at this code 25
years from now?

>> And whether you consider those guidelines in general to "aim for the
>> lowest common denominator" is debatable. The fact one may be convinced
>> to know better than those guidelines is also highly questionable.
>
> There are other considerations. Sometimes respecting your team's
> ability to get it right without a thick tome of guidelines works
> better.
>
>> Similar rules can be seen in other similar standards/coding
>> guidelines. Apparently no one that answered here have ever ahd to deal
>> with any of those, otherwise what I said would probably sound pretty
>> obvious.
>
> I have. I hated it. I looked for another job where I was trusted to
> write readable code.
>

I have had to write code to MISRA standards a couple of times. Some
aspects were fine, others were annoying, but it is not the worst I have
dealt with. Maintaining code written with no thought or regard to
readability, or by smart-arse programmers, is worse IME. A coding
standard does not force people to write clear code, nor does a lack of a
standard imply code is not clear. But standards can limit some of the
worst aspects of code.

David Brown <david.brown@hesbynett.no> writes:

> I have had to write code to MISRA standards a couple of times. Some
> aspects were fine, others were annoying, but it is not the worst I
> have dealt with. Maintaining code written with no thought or regard
> to readability, or by smart-arse programmers, is worse IME. A coding
> standard does not force people to write clear code, nor does a lack of
> a standard imply code is not clear. But standards can limit some of
> the worst aspects of code.

Compared to many here, my experience is limited, but I did not get that
impression from that limited experience. Coding standards are almost
always about the surface syntax, and all the headaches I remember having
with other people's code had nothing whatsoever to do with the surface
syntax.

--
Ben.

Le 11/04/2022 à 22:27, Ben a écrit :
> I shall have to remain in the dark then about what you consider a good
> start because the quote "Limited dependence should be placed on operator
> precedence rules in expressions" I think MISRA costs money.

If you use MISRA in a professional context, you should of course buy a
copy, but if you're just curious or it's for your own personal use, then
it's easy to get ahold of a copy.

But I explicitely mentioned the rule number that applied here, and with
this number, you'll find the details online very easily without needing
to get the whole document.

The same kind of issue can be found here:
https://cwe.mitre.org/data/definitions/783.html , and this rule is also
part of CERT-C.

Guillaume <message@bottle.org> writes:

> Le 11/04/2022 à 22:27, Ben a écrit :
>> I shall have to remain in the dark then about what you consider a good
>> start because the quote "Limited dependence should be placed on operator
>> precedence rules in expressions" I think MISRA costs money.
>
> If you use MISRA in a professional context, you should of course buy a
> copy, but if you're just curious or it's for your own personal use,
> then it's easy to get ahold of a copy.
>
> But I explicitely mentioned the rule number that applied here, and
> with this number, you'll find the details online very easily without
> needing to get the whole document.

I didn't succeed. Only spent a few minutes but all I could find is
people quoting some (or many all of) that rule in compliance statements.

One says:

"MISRA C:2012 Rule 12.1: The precedence of operators within
expressions should be made explicit"

but that can't be the whole rule and, as quoted, it sounds very odd.

> The same kind of issue can be found here:
> https://cwe.mitre.org/data/definitions/783.html , and this rule is
> also part of CERT-C.

I could not find a rule on that page, but then it has a lot of detailed
content. I found "Potential mitigations":

"Regularly wrap sub-expressions in parentheses, especially in
security-critical code."

but that hardly helps to know where anyone draws the line.

--
Ben.

On 14/04/2022 15:07, Ben wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> I have had to write code to MISRA standards a couple of times. Some
>> aspects were fine, others were annoying, but it is not the worst I
>> have dealt with. Maintaining code written with no thought or regard
>> to readability, or by smart-arse programmers, is worse IME. A coding
>> standard does not force people to write clear code, nor does a lack of
>> a standard imply code is not clear. But standards can limit some of
>> the worst aspects of code.
>
> Compared to many here, my experience is limited, but I did not get that
> impression from that limited experience. Coding standards are almost
> always about the surface syntax, and all the headaches I remember having
> with other people's code had nothing whatsoever to do with the surface
> syntax.
>

I certainly have had headaches from what you might call "surface syntax"
(noting that without trying to give a definition of that term, we might
be talking past each other), though I agree that the worst headaches
come from other aspects of the code. And on the other side, MISRA and
many other standards are not restricted solely to "surface syntax".

Coding standard rules, IMHO, can usually be grouped as obvious (such as
"don't rely on undefined behaviour"), useful, and counter-productive for
at least some times of code (such as banning compiler-specific features,
which will often make microcontroller code impossible to write). The
division lines are not constant, and there is some overlap. Coding
standards need to be used carefully and appropriately, not blindly.

Directive 1.1 of MISRA C 2012 says "Any implementation-defined behaviour
on which the output of the program depends shall be documented and
understood". That is far from "surface syntax", and a good idea (albeit
one never fully implemented in practice).

On 15/04/2022 20:25, Ben wrote:
> Guillaume <message@bottle.org> writes:
>
>> Le 11/04/2022 à 22:27, Ben a écrit :
>>> I shall have to remain in the dark then about what you consider a good
>>> start because the quote "Limited dependence should be placed on operator
>>> precedence rules in expressions" I think MISRA costs money.
>>
>> If you use MISRA in a professional context, you should of course buy a
>> copy, but if you're just curious or it's for your own personal use,
>> then it's easy to get ahold of a copy.
>>
>> But I explicitely mentioned the rule number that applied here, and
>> with this number, you'll find the details online very easily without
>> needing to get the whole document.
>
> I didn't succeed. Only spent a few minutes but all I could find is
> people quoting some (or many all of) that rule in compliance statements.
>
> One says:
>
> "MISRA C:2012 Rule 12.1: The precedence of operators within
> expressions should be made explicit"
>
> but that can't be the whole rule and, as quoted, it sounds very odd.
>

It is not the whole rule, which is fleshed out more and has a number of
examples. It is also an "advisory" rule, rather than a "required" rule,
and it contains the rationale note:

"""
It is recognized that overuse of parentheses can clutter the code and
reduce its readability. This rule aims to achieve a compromise between
code that is hard to understand because it contains either too many or
too few parentheses.
"""

Whether or not you think it succeeds in this aim is, clearly, a matter
of opinion!

An example of a non-compliant expression is :

x = a == b ? a : a - b;

with the compliant version being :

x = ( a == b ) ? a : ( a - b );

Personally, I'd write the second form, but with different spacing:

x = (a == b) ? a : (a - b);

To my eyes, that is the version that is quickest to parse correctly, and
least likely for anyone to parse incorrectly no matter how much or how
little time they spent looking at it, or how familiar they are with the
precedence rules of the language.

On 2022-04-18, David Brown <david.brown@hesbynett.no> wrote:
> On 15/04/2022 20:25, Ben wrote:
>> Guillaume <message@bottle.org> writes:
>>
>>> Le 11/04/2022 à 22:27, Ben a écrit :
>>>> I shall have to remain in the dark then about what you consider a good
>>>> start because the quote "Limited dependence should be placed on operator
>>>> precedence rules in expressions" I think MISRA costs money.
>>>
>>> If you use MISRA in a professional context, you should of course buy a
>>> copy, but if you're just curious or it's for your own personal use,
>>> then it's easy to get ahold of a copy.
>>>
>>> But I explicitely mentioned the rule number that applied here, and
>>> with this number, you'll find the details online very easily without
>>> needing to get the whole document.
>>
>> I didn't succeed. Only spent a few minutes but all I could find is
>> people quoting some (or many all of) that rule in compliance statements.
>>
>> One says:
>>
>> "MISRA C:2012 Rule 12.1: The precedence of operators within
>> expressions should be made explicit"
>>
>> but that can't be the whole rule and, as quoted, it sounds very odd.
>>
>
> It is not the whole rule, which is fleshed out more and has a number of
> examples. It is also an "advisory" rule, rather than a "required" rule,
> and it contains the rationale note:
>
> """
> It is recognized that overuse of parentheses can clutter the code and
> reduce its readability. This rule aims to achieve a compromise between
> code that is hard to understand because it contains either too many or
> too few parentheses.
> """
>
> Whether or not you think it succeeds in this aim is, clearly, a matter
> of opinion!
>
> An example of a non-compliant expression is :
>
> x = a == b ? a : a - b;
>
> with the compliant version being :
>
> x = ( a == b ) ? a : ( a - b );

This is actually a really poor example.

What if I don't remember whether = has a lower precedence than ?:

If your answer is that it obviously does, then we can easily
argue that, likewise, == and - "obviously" have a higher precedence, and
so nothing needs parenthesizing.

Rather, if I were only allowed to insert one set of parentheses, I would
prioritize the insertion of this pair:

x = (a == b ? a : a - b)

Then if additional parens were still needed:

x = ((a == b) ? (a) : (a - b))

The inner one is for consistency: a is parallel with a - b.
This is analogous to bracing both branches of if/else if one
branch is braced.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 18/04/2022 18:38, Kaz Kylheku wrote:
> On 2022-04-18, David Brown <david.brown@hesbynett.no> wrote:
>> On 15/04/2022 20:25, Ben wrote:
>>> Guillaume <message@bottle.org> writes:
>>>
>>>> Le 11/04/2022 à 22:27, Ben a écrit :
>>>>> I shall have to remain in the dark then about what you consider a good
>>>>> start because the quote "Limited dependence should be placed on operator
>>>>> precedence rules in expressions" I think MISRA costs money.
>>>>
>>>> If you use MISRA in a professional context, you should of course buy a
>>>> copy, but if you're just curious or it's for your own personal use,
>>>> then it's easy to get ahold of a copy.
>>>>
>>>> But I explicitely mentioned the rule number that applied here, and
>>>> with this number, you'll find the details online very easily without
>>>> needing to get the whole document.
>>>
>>> I didn't succeed. Only spent a few minutes but all I could find is
>>> people quoting some (or many all of) that rule in compliance statements.
>>>
>>> One says:
>>>
>>> "MISRA C:2012 Rule 12.1: The precedence of operators within
>>> expressions should be made explicit"
>>>
>>> but that can't be the whole rule and, as quoted, it sounds very odd.
>>>
>>
>> It is not the whole rule, which is fleshed out more and has a number of
>> examples. It is also an "advisory" rule, rather than a "required" rule,
>> and it contains the rationale note:
>>
>> """
>> It is recognized that overuse of parentheses can clutter the code and
>> reduce its readability. This rule aims to achieve a compromise between
>> code that is hard to understand because it contains either too many or
>> too few parentheses.
>> """
>>
>> Whether or not you think it succeeds in this aim is, clearly, a matter
>> of opinion!
>>
>> An example of a non-compliant expression is :
>>
>> x = a == b ? a : a - b;
>>
>> with the compliant version being :
>>
>> x = ( a == b ) ? a : ( a - b );
>
> This is actually a really poor example.
>
> What if I don't remember whether = has a lower precedence than ?:

You have to require /some/ knowledge of C. Assignments are the lowest
precedence (other than the comma operator, which MISRA bans or at least
strongly discourages anyway). Similarly, MISRA expects you to
understand that the unary operators have higher precedence.

>
> If your answer is that it obviously does, then we can easily
> argue that, likewise, == and - "obviously" have a higher precedence, and
> so nothing needs parenthesizing.
>
> Rather, if I were only allowed to insert one set of parentheses, I would
> prioritize the insertion of this pair:
>
> x = (a == b ? a : a - b)
>
> Then if additional parens were still needed:
>
> x = ((a == b) ? (a) : (a - b))
>
> The inner one is for consistency: a is parallel with a - b.
> This is analogous to bracing both branches of if/else if one
> branch is braced.
>

To me, this is not so much a matter of remembering the precedence rules
as being able to tell at a glance what the expression means - and making
it as difficult as possible for (almost) anyone to misinterpret it when
reading it, even if they have different habits for spacing or
parenthesising.

I believe it is highly unlikely for "x=a + b;" to be misinterpreted,
thus adding parenthesis is unhelpful. But "x=a == b?a:a-b;" could
certainly lead to confusion, or at least longer parse times - putting
parenthesis as suggested by MISRA would help, putting them where you
suggested would not.

(There are no absolute facts here - only opinions, preferences, and
experiences. Maybe there are also studies and statistics - MISRA is a
large industry body that does that kind of thing, unlike this newsgroup!)

On 4/18/22 08:12, David Brown wrote:
> On 15/04/2022 20:25, Ben wrote:
....
>> One says:
>>
>> "MISRA C:2012 Rule 12.1: The precedence of operators within
>> expressions should be made explicit"
>>
>> but that can't be the whole rule and, as quoted, it sounds very odd.
>>
>
> It is not the whole rule, which is fleshed out more and has a number of
> examples. It is also an "advisory" rule, rather than a "required" rule,
> and it contains the rationale note:
>
> """
> It is recognized that overuse of parentheses can clutter the code and
> reduce its readability. This rule aims to achieve a compromise between
> code that is hard to understand because it contains either too many or
> too few parentheses.
> """
>
> Whether or not you think it succeeds in this aim is, clearly, a matter
> of opinion!
>
> An example of a non-compliant expression is :
>
> x = a == b ? a : a - b;
>
> with the compliant version being :
>
> x = ( a == b ) ? a : ( a - b );
>
>
> Personally, I'd write the second form, but with different spacing:
>
> x = (a == b) ? a : (a - b);
>
> To my eyes, that is the version that is quickest to parse correctly, and
> least likely for anyone to parse incorrectly no matter how much or how
> little time they spent looking at it, or how familiar they are with the
> precedence rules of the language.
>

This reminds be a discussion I had in 2014 (with you, in fact) about
MISRA Rule 34 (required):
"The operands of a logical && or || shall be primary expressions if the
operands contain binary operators."

I pointed out that this rule mandates that at least one pair of
parentheses be inserted in the following expression:

(a && b) && c

because '&&' is a binary operator, and a && b is the left operand of the
second && operator.

I also pointed out that, "the operands contain" could either be
interpreted as meaning "both operands contain", which would allow a + b
&& c, or "either operand contains", which would require (a+b) && (c).

As far as I can tell from the MISRA rules I've been told about so far,
they are often poorly thought out, poorly written, or overly restrictive.

On 2022-04-18, David Brown <david.brown@hesbynett.no> wrote:
> On 18/04/2022 18:38, Kaz Kylheku wrote:
>> On 2022-04-18, David Brown <david.brown@hesbynett.no> wrote:
>>> On 15/04/2022 20:25, Ben wrote:
>>>> Guillaume <message@bottle.org> writes:
>>>>
>>>>> Le 11/04/2022 à 22:27, Ben a écrit :
>>>>>> I shall have to remain in the dark then about what you consider a good
>>>>>> start because the quote "Limited dependence should be placed on operator
>>>>>> precedence rules in expressions" I think MISRA costs money.
>>>>>
>>>>> If you use MISRA in a professional context, you should of course buy a
>>>>> copy, but if you're just curious or it's for your own personal use,
>>>>> then it's easy to get ahold of a copy.
>>>>>
>>>>> But I explicitely mentioned the rule number that applied here, and
>>>>> with this number, you'll find the details online very easily without
>>>>> needing to get the whole document.
>>>>
>>>> I didn't succeed. Only spent a few minutes but all I could find is
>>>> people quoting some (or many all of) that rule in compliance statements.
>>>>
>>>> One says:
>>>>
>>>> "MISRA C:2012 Rule 12.1: The precedence of operators within
>>>> expressions should be made explicit"
>>>>
>>>> but that can't be the whole rule and, as quoted, it sounds very odd.
>>>>
>>>
>>> It is not the whole rule, which is fleshed out more and has a number of
>>> examples. It is also an "advisory" rule, rather than a "required" rule,
>>> and it contains the rationale note:
>>>
>>> """
>>> It is recognized that overuse of parentheses can clutter the code and
>>> reduce its readability. This rule aims to achieve a compromise between
>>> code that is hard to understand because it contains either too many or
>>> too few parentheses.
>>> """
>>>
>>> Whether or not you think it succeeds in this aim is, clearly, a matter
>>> of opinion!
>>>
>>> An example of a non-compliant expression is :
>>>
>>> x = a == b ? a : a - b;
>>>
>>> with the compliant version being :
>>>
>>> x = ( a == b ) ? a : ( a - b );
>>
>> This is actually a really poor example.
>>
>> What if I don't remember whether = has a lower precedence than ?:
>
> You have to require /some/ knowledge of C. Assignments are the lowest
> precedence (other than the comma operator, which MISRA bans or at least
> strongly discourages anyway). Similarly, MISRA expects you to
> understand that the unary operators have higher precedence.
>
>>
>> If your answer is that it obviously does, then we can easily
>> argue that, likewise, == and - "obviously" have a higher precedence, and
>> so nothing needs parenthesizing.
>>
>> Rather, if I were only allowed to insert one set of parentheses, I would
>> prioritize the insertion of this pair:
>>
>> x = (a == b ? a : a - b)
>>
>> Then if additional parens were still needed:
>>
>> x = ((a == b) ? (a) : (a - b))
>>
>> The inner one is for consistency: a is parallel with a - b.
>> This is analogous to bracing both branches of if/else if one
>> branch is braced.
>>
>
> To me, this is not so much a matter of remembering the precedence rules
> as being able to tell at a glance what the expression means - and making
> it as difficult as possible for (almost) anyone to misinterpret it when
> reading it, even if they have different habits for spacing or
> parenthesising.
>
> I believe it is highly unlikely for "x=a + b;" to be misinterpreted,
> thus adding parenthesis is unhelpful. But "x=a == b?a:a-b;" could
> certainly lead to confusion, or at least longer parse times - putting
> parenthesis as suggested by MISRA would help, putting them where you
> suggested would not.

Sure, OK. But then, what is the point of the "x = " in the MISRA
example?

x = ( a == b ) ? a : ( a - b );

The possibility remains that this be misread as:

(x = ( a == b )) ? a : ( a - b );

Why is the assignment included in this example; if its apparent
ambiguity isn't being taken care of?

What it is that the reader is supposed to be confused by if we remove
the left pair of parentheses.

x = a == b ? a : ( a - b );

Are the parentheses supposed to rule out this misparse?

x = a == (b ? a : ( a - b )).

If so, that can be demonstrated without the x = because it's
an internal matter within just ternary expression.

Or is it this misparse:

(x = a) == b ? a : ( a - b ).

But that is an issue between just the = and == operator that
can be put into a simpler recommendation, like

"parenthesize equality/inequality expressions that are next to
assignment operators. Don't write:

flag = foo == bar

but

flag = (foo == bar)

or

row += i % 10 == 0

but rather

row += (i % 10 == 0)"

The thing is that x = y ? z : w is actually a famous ambiguity,
which revolves around the precedence of = versus ?:.
Someone who thinks = is higher misreads it as (x = y) ? z : w.
This can be a valid interpretation of z and w have side effects.

Parenthesizing y does nothing: x = (y) ? z : w.

You need: x = (y ? z : w). Aha, only y is tested, and then
x receives either z or w.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal