Velocity Reviews > In how many ways should this fail?

# In how many ways should this fail?

Kaz Kylheku
Guest
Posts: n/a

 01-30-2012
On 2012-01-30, timprince <(E-Mail Removed)> wrote:
> On 1/30/2012 10:32 AM, Anders Wegge Keller wrote:
>>
>> 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;

(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
Guest
Posts: n/a

 01-30-2012
James Kuyper <(E-Mail Removed)> writes:

> [...] 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++.

--
Ben.

jacob navia
Guest
Posts: n/a

 01-30-2012
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
Guest
Posts: n/a

 01-30-2012
Anders Wegge Keller <(E-Mail Removed)> writes:

> 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....c_5.html#SEC76
It was never standard, rarely useful, and removed from GCC 4.x.
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin

BartC
Guest
Posts: n/a

 01-30-2012

"James Kuyper" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 01/30/2012 11:43 AM, BartC wrote:
>>
>>
>> "Devil with the China Blue Dress" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)-september.org...
>>> In article <(E-Mail Removed)>,
>>> Anders Wegge Keller <(E-Mail Removed)> wrote:
>>>
>>>> At work, we got into a talk about weird C constructs. One of my
>>>> collegues volunteered this line:
>>>>
>>>> (a>b)?a:b = 42;
>>>
>>> *(a>b ? &a : &b) = 42;

>>
>> 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;

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?

--
Bartc

Anders Wegge Keller
Guest
Posts: n/a

 01-30-2012
gwowen <(E-Mail Removed)> writes:

> On Jan 30, 3:32Â*pm, Anders Wegge Keller <(E-Mail Removed)> wrote:
>
> > Â*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);

Worse than that:

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

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

BartC
Guest
Posts: n/a

 01-30-2012
"jacob navia" <(E-Mail Removed)> wrote in message
news:jg6m3s\$1n6\$(E-Mail Removed)...
> 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.

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);

--
bartc

Anders Wegge Keller
Guest
Posts: n/a

 01-30-2012
Kaz Kylheku <(E-Mail Removed)> writes:

> On 2012-01-30, Anders Wegge Keller <(E-Mail Removed)> wrote:
> >
> > At work, we got into a talk about weird C constructs. One of my
> > collegues volunteered this line:
> >
> > (a>b)?a:b = 42;

...

>> 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.

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

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

James Kuyper
Guest
Posts: n/a

 01-30-2012
On 01/30/2012 01:16 PM, BartC wrote:
>
>
> "James Kuyper" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On 01/30/2012 11:43 AM, BartC wrote:
>>>
>>>
>>> "Devil with the China Blue Dress" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)-september.org...
>>>> In article <(E-Mail Removed)>,
>>>> Anders Wegge Keller <(E-Mail Removed)> wrote:
>>>>
>>>>> At work, we got into a talk about weird C constructs. One of my
>>>>> collegues volunteered this line:
>>>>>
>>>>> (a>b)?a:b = 42;
>>>>
>>>> *(a>b ? &a : &b) = 42;
>>>
>>> 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;

>
> 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
Guest
Posts: n/a

 01-30-2012
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.