In how many ways should this fail?

[Anders Wegge Keller]

At work, we got into a talk about weird C constructs. One of my
collegues volunteered this line:

(a>b)?a:b = 42;

According to him, he have found three different compilers with three
different ways of handling this. One did nothing, one always assigned
to b, and the last one did what one should expect, were it legal.

We ended up discussing what the acutal problem here is. The
diffrerent compilers we had at hand gave different diagnostics, so
they giv no clue. We narrowed it down to one of two:

1) a and b are not lvalues in this context.

2) This expression invokes undefined behaviour, since there are no
sequence point between (a>b) and the assignment.

 

[James Kuyper]

At work, we got into a talk about weird C constructs. One of my
collegues volunteered this line:

(a>b)?a:b = 42;

According to him, he have found three different compilers with three
different ways of handling this. One did nothing, one always assigned
to b, and the last one did what one should expect, were it legal.

We ended up discussing what the acutal problem here is. The
diffrerent compilers we had at hand gave different diagnostics, so
they giv no clue. We narrowed it down to one of two:

1) a and b are not lvalues in this context.

That's true, but not relevant. The key issue is that the C standard
fails to specify that it's an lvalue - but to make it clear that this
wasn't an oversight, footnote 95 says "A conditional expression does not
yield an lvalue." As a result, its result cannot be assigned to. Note
that this is one of the differences between C and C++; the result of a
?: expression is an lvalue in C++.

2) This expression invokes undefined behaviour, since there are no
sequence point between (a>b) and the assignment.

6.5.15 "Conditional operator" p4: "The first operand is evaluated; there
is a sequence point after its evaluation." Since you need to evaluate
the ?: expression to determine what should be assigned to; there is
indeed a sequence point between the evaluation of the > operation and
the assignment. If you'd avoided the other problem by writing

*((a>b)?&a : &b) = 42;

there would not have been a problem.

 

[James Kuyper]

That's true, but not relevant. The key issue is that the C standard
fails to specify that it's an lvalue

In the course of editing that sentence, I accidentally removed the thing
that "it" refers to. That sentence should have said: "The key issue is
that the C standard fails to specify that the result of a conditional
expression is an lvalue."

 

[gwowen]

 According to him, he have found three different compilers with three
different ways of handling this. One did nothing, one always assigned
to b, and the last one did what one should expect, were it legal.

What should one expect?

(a>b) ? a : (b=42);

In C (given that [foo() ? a : b] isn't an lvalue), that seems a
perfectly sensible parse to me. One might even do

x = ((a>b) ? a : (b=42));

as a truly horrible way of writing

if(a>b) {
x = a;
} else {
x = b = 42;
}

In C++, obviously
(a > b ? a : b) = 42;
is a reasonable parse.

As ever, anyone who fails to use enough parenthesis to unambiguously
express intent, needs a good hard slap.

 

[BartC]

*(a>b ? &a : &b) = 42;

There's no reason why the original version shouldn't work. Doing as you
suggest is a bit like writing:

*(&a) = 42;

instead of a = 42. It shouldn't be necessary and it's less readable.

 

[timprince]

At work, we got into a talk about weird C constructs. One of my
collegues volunteered this line:

(a>b)?a:b = 42;

According to him, he have found three different compilers with three
different ways of handling this. One did nothing, one always assigned
to b, and the last one did what one should expect, were it legal.

We ended up discussing what the acutal problem here is. The
diffrerent compilers we had at hand gave different diagnostics, so
they giv no clue. We narrowed it down to one of two:

1) a and b are not lvalues in this context.

2) This expression invokes undefined behaviour, since there are no
sequence point between (a>b) and the assignment.

You may require additional parentheses to use this extension more
reliably (and force diagnostics when it is interpreted as a do-nothing):
((a>b)?a:b) = 42;
Under compilers which support this extension, you would need to set
standards checking options to reject it and get a complaint. Other
compilers I have used will reject it with a diagnostic.

 

[Kaz Kylheku]

At work, we got into a talk about weird C constructs. One of my
collegues volunteered this line:

(a>b)?a:b = 42;

According to him, he have found three different compilers with three
different ways of handling this.

Some compilers accept a nonstandard dialect with extensions by default and have
to be told to interpret the input language as ISO C.

In the GNU C dialect, it is possible assign "through" the ternary operator.

In the C++ dialect of C, you can do this also, so if you compile code as either
C or C++, you may run into this working under C++, but then breaking when
someone runs the C build.

ISO C does not have this feature: the result of A ? B : C is not an lvalue.

Very recent case in point: http://www.kylheku.com/cgit/txr/commit/?id=5ae4654a4c6961d35b9bb4833934c51f17936df6

We ended up discussing what the acutal problem here is.

Probably, that of not knowing that there exist different dialects of C, and that
your compiler might not be using the one you think it is.

 

[Kaz Kylheku]

There's no reason why the original version shouldn't work. Doing as you
suggest is a bit like writing:

*(&a) = 42;

instead of a = 42. It shouldn't be necessary and it's less readable.

It isn't necessary in the "better C" known as C++. Why not use that?
Ah right, portability.

The *(a>b ? &a : &b) = 42; method works in both C and C++.

The ternary syntax is awful anyway. Any time you nest it or combine it
with adjacent operators it becomes hard to decipher the precedence.

A function-like syntax both problems:

#define IF(a,b,c) ((a) ? (b) : (c)))
#define IFL(a,b,c) (*((a) ? &(b) : &(c)))

IFL(foo != bar(), a, b) = x | FLAG;

 

[James Kuyper]

There's no reason why the original version shouldn't work. ...

That depends upon what you mean by "work". The original expression is
equivalent to

b = 42;

Which is unlikely to be what the author intended, and would be a pretty
bizarre way of writing it if that was what he intended. Assuming that
the parentheses needed to force the intended parse are inserted, there's
still the problem that ((a>b)?a:b) isn't an lvalue.

... Doing as you
suggest is a bit like writing:

*(&a) = 42;

instead of a = 42. ...

There's one key difference: *((a>b) ? &a : &b) = 42 is necessary in C,
*(&a) = 42 is not.

... It shouldn't be necessary and it's less readable.

You're arguably correct about that. C++ allows the original expression
to work as intended, even though C does not. This is because the C++
grammar differs from the C grammar by not allowing the third operand to
be an assignment expression, and the C++ standard specifies that the
result is an lvalue. They made the change because it makes some things
involving C++ classes are more convenient; but the fact that it has been
done is C++ means it could be done in C - that fact doesn't depend upon
any C++-specific features.

 

[Ben Bacarisse]

<talking about:>

a > b ? a : b = 42;

What should one expect?

(a>b) ? a : (b=42);

In C (given that [foo() ? a : b] isn't an lvalue), that seems a
perfectly sensible parse to me.

It might be sensible, but it's no what C's syntax mandates. A
conforming compiler must parse it as

((a > b) ? a : b) = 42;

In C++, obviously
(a > b ? a : b) = 42;
is a reasonable parse.

Again, it's reasonable... but wrong. The original expression must parse
as

(a > b) ? a : (b = 42);

The differences between C and C++ here are two-fold: not only can a
conditional expression be an l-value, but the syntax is also different.
An assignment is valid after the ':' in C++ but not in C.

Lots of operator precedence tables that claim be for "C/C++" get this
wrong.

As ever, anyone who fails to use enough parenthesis to unambiguously
express intent, needs a good hard slap.

Particularly in this case!

 

[Kaz Kylheku]

You may require additional parentheses to use this extension more
reliably (and force diagnostics when it is interpreted as a do-nothing):
((a>b)?a:b) = 42;

(a>b)?a:b = 42; means the same thing as ((a>b)?a:b) = 42

(whatever it happens to mean).

The parens would be necessar only if you need to port your code some poor
quality compilers that cannot correctly parse the precedence of an assignment
expression relative to a ternary operator.

The extension is not syntactic but semantic.

 

[Ben Bacarisse]

[...] Note
that this is one of the differences between C and C++; the result of a
?: expression is an lvalue in C++.

I'd say "can be a lvalue" since it is not always an lvalue in C++. It's
probably also worth pointing out that the syntax is different between C
and C++. The original means (a > b ? a : b) = 42; in C, but it means
a > b ? a : (b = 42); in C++.

 

[jacob navia]

Le 30/01/12 16:32, Anders Wegge Keller a écrit :

At work, we got into a talk about weird C constructs. One of my
collegues volunteered this line:

(a>b)?a:b = 42;

lcc-win diagnostics this as an error. A ternary operator construct
is not an lvalue.

 

[Ben Pfaff]

At work, we got into a talk about weird C constructs. One of my
collegues volunteered this line:

(a>b)?a:b = 42;

GCC 2.x and 3.x had an extension that allowed ?: to yield an
lvalue:
http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_5.html#SEC76
It was never standard, rarely useful, and removed from GCC 4.x.

 

[BartC]

That depends upon what you mean by "work". The original expression is
equivalent to

b = 42;

Only if the precedence of ?: is lower than for assignment. Used the other
way:

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

You would expect the conditional expression to be evaluated first. Why not
the same with the conditional on the left?

 

[Anders Wegge Keller]

What should one expect?

(a>b) ? a : (b=42);

Worse than that:

(a>b) ? (a=42) : (b=42);

 

[BartC]

Le 30/01/12 16:32, Anders Wegge Keller a écrit :

lcc-win diagnostics this as an error. A ternary operator construct
is not an lvalue.

Strangely, your compiler was the only one of four where this worked
completely as expected!

int a=400;
int b=300;

printf("A=%d B=%d\n",a,b);

(a>b)?a:b = 42;

printf("A'=%d B'=%d\n",a,b);

 

[Anders Wegge Keller]

...

Probably, that of not knowing that there exist different dialects of
C, and that your compiler might not be using the one you think it
is.

No, actually we were discussing why this was prohibited under ISO C,
and wondering exactly *what* part of the standard was violated.

 

[James Kuyper]

Only if the precedence of ?: is lower than for assignment. Used the other
way:

The ?: operator can't be explained in terms of a simple precedence
relative to other operators.

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

You would expect the conditional expression to be evaluated first. Why not
the same with the conditional on the left?

Because I when gwowen wrote his comment, it sounded familiar, like
something I already knew to be true, so I didn't bother to check. I just
checked, and he was wrong, and I was therefore wrong to agree with his
parse. The C grammar is:

logical-OR-expression ? expression : conditional-expression

In the following lines, I've inserted spaces to make corresponding parts
line up with each other, but the alignment will not come out correctly
unless viewed using a monospaced font:

According to that grammar,
a || b ? d , e : f ? g : h
must be parsed as
(a || b) ? (d , e) : (f ? g : h)
but
a ? b : c ? d , e : f = g
must be parsed as
(a ? b : (c ? (d , e) : f)) = g
(that last parse results in a constraint violation, but it's not a
syntax error).

In all other contexts, the C grammar can be understood as giving || a
higher precedence than =, giving both of them higher precedence than the
comma operator. However, there's no way to insert ?: into that
precedence hierarchy that explains both of the above parses.

The C++ grammar is different, as I said, but I had the difference backwards:
logical-or-expression ? expression : assignment-expression

and that's probably what both gwowen and I were thinking about. In C++
a || b ? d , e : f = g
parses as:
(a || b) ? (d , e) : (f = g)
while
a ? b : c ? d , e : f , g
parses as:
(a ? (b : c ? (d , e) : f)), g

which is even harder to explain by inserting the ?: anywhere into the
precedence hierarchy relative to ||, =, and the comma operator.

 

[88888 Dihedral]

Arbitrary assignment operation in any parenthesis allowed in C is just teasing
programmers to write more debates for collecting taxes in books about C
programming.

Pascal and Fortran are better in this issue.