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

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

In how many ways should this fail?

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

Contents

  In how many ways should this fail? Anders Wegge Keller <wegge@wegge.dk> - 2012-01-30 16:32 +0100
    Re: In how many ways should this fail? James Kuyper <jameskuyper@verizon.net> - 2012-01-30 11:07 -0500
      Re: In how many ways should this fail? James Kuyper <jameskuyper@verizon.net> - 2012-01-30 11:11 -0500
      Re: In how many ways should this fail? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-30 17:42 +0000
    Re: In how many ways should this fail? gwowen <gwowen@gmail.com> - 2012-01-30 08:16 -0800
      Re: In how many ways should this fail? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-30 17:35 +0000
        Re: In how many ways should this fail? gwowen <gwowen@gmail.com> - 2012-01-30 23:47 -0800
        Re: In how many ways should this fail? Tim Rentsch <txr@alumni.caltech.edu> - 2012-02-01 00:00 -0800
          Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-02-01 12:14 +0000
            Re: In how many ways should this fail? James Kuyper <jameskuyper@verizon.net> - 2012-02-01 08:04 -0500
            Re: In how many ways should this fail? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-01 13:31 +0000
          Re: In how many ways should this fail? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-01 12:59 +0000
            Re: In how many ways should this fail? James Kuyper <jameskuyper@verizon.net> - 2012-02-01 08:37 -0500
              Re: In how many ways should this fail? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-01 16:40 +0000
                Re: In how many ways should this fail? James Kuyper <jameskuyper@verizon.net> - 2012-02-01 12:13 -0500
                  Re: In how many ways should this fail? Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 12:49 -0800
      Re: In how many ways should this fail? Anders Wegge Keller <wegge@wegge.dk> - 2012-01-30 19:20 +0100
    Re: In how many ways should this fail? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-01-30 08:30 -0800
      Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-01-30 16:43 +0000
        Re: In how many ways should this fail? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-01-30 09:17 -0800
        Re: In how many ways should this fail? Kaz Kylheku <kaz@kylheku.com> - 2012-01-30 17:31 +0000
        Re: In how many ways should this fail? James Kuyper <jameskuyper@verizon.net> - 2012-01-30 12:31 -0500
          Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-01-30 18:16 +0000
            Re: In how many ways should this fail? James Kuyper <jameskuyper@verizon.net> - 2012-01-30 14:05 -0500
              Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-01-30 19:30 +0000
                Re: In how many ways should this fail? Keith Thompson <kst-u@mib.org> - 2012-01-30 12:50 -0800
                Re: In how many ways should this fail? James Kuyper <jameskuyper@verizon.net> - 2012-01-30 16:17 -0500
                Re: In how many ways should this fail? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-30 21:48 +0000
                  Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-01-31 12:43 +0000
                    Re: In how many ways should this fail? Zoltan Kocsi <zoltan@bendor.com.au> - 2012-02-01 00:46 +1100
                    Re: In how many ways should this fail? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-31 13:57 +0000
                      Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-01-31 15:05 +0000
                        Re: In how many ways should this fail? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-01-31 07:16 -0800
                          Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-01-31 17:37 +0000
                        Re: In how many ways should this fail? James Kuyper <jameskuyper@verizon.net> - 2012-01-31 11:34 -0500
                          Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-01-31 17:39 +0000
                        Re: In how many ways should this fail? Keith Thompson <kst-u@mib.org> - 2012-01-31 19:42 -0800
                          Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-02-01 11:57 +0000
                            Re: In how many ways should this fail? James Kuyper <jameskuyper@verizon.net> - 2012-02-01 08:14 -0500
                      Re: In how many ways should this fail? Philip Lantz <prl@canterey.us> - 2012-02-01 00:04 -0800
                    Re: In how many ways should this fail? James Kuyper <jameskuyper@verizon.net> - 2012-01-31 09:05 -0500
                    Re: In how many ways should this fail? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-01-31 06:45 -0800
                      Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-01-31 17:34 +0000
                    Re: In how many ways should this fail? Keith Thompson <kst-u@mib.org> - 2012-01-31 19:26 -0800
                    Re: In how many ways should this fail? Keith Thompson <kst-u@mib.org> - 2012-01-31 19:29 -0800
          Re: In how many ways should this fail? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-30 21:28 +0000
    Re: In how many ways should this fail? timprince <tprince@computer.org> - 2012-01-30 11:44 -0500
      Re: In how many ways should this fail? Kaz Kylheku <kaz@kylheku.com> - 2012-01-30 17:35 +0000
    Re: In how many ways should this fail? Kaz Kylheku <kaz@kylheku.com> - 2012-01-30 17:21 +0000
      Re: In how many ways should this fail? Anders Wegge Keller <wegge@wegge.dk> - 2012-01-30 19:22 +0100
        Re: In how many ways should this fail? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-30 11:09 -0800
    Re: In how many ways should this fail? jacob navia <jacob@spamsink.net> - 2012-01-30 19:04 +0100
      Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-01-30 18:21 +0000
        Re: In how many ways should this fail? Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-30 20:15 +0100
          Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-01-30 19:32 +0000
            Re: In how many ways should this fail? Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-30 21:01 +0100
              Re: In how many ways should this fail? "BartC" <bc@freeuk.com> - 2012-01-30 20:22 +0000
                Re: In how many ways should this fail? Keith Thompson <kst-u@mib.org> - 2012-01-30 12:56 -0800
    Re: In how many ways should this fail? blp@cs.stanford.edu (Ben Pfaff) - 2012-01-30 10:07 -0800

Page 3 of 3 — ← Prev page 1 2 [3]

#16488

On 01/31/2012 07:43 AM, BartC wrote:
...
> OK, so the C standard uses a far more pedantic and unwieldy way of 
> expressing syntax than I would, ...

Which is probably a very good thing.

> ... if it has to enforce each of the 17 
> precedence levels in the grammar!
> 
> (I would write the formal syntax as just:
> 
>  expr ? expr : expr
> 
> worrying about any restrictions on each expr later, while the production of 
> 'expr' doesn't itself worry about precedence (which would just be an 
> attribute of a binary operator).

The method the committee decided to use to describe the grammar rules is
more powerful and subtle than the one you're suggesting, and I think
that they were right to use it, and did a fairly good job of using it.

...
>> assignment-expression:
>>   conditional-expression
>>   unary-expression assignment-operator assignment-expression
>>
>> just says that an assignment expression can be a conditional expression
>> on its own.
> 
> You have to look further into the Standard to discover that 
> 'assignment-expression' just means 'any expression'.

Not true: the grammar productions for "expression" (6.5.17p1) are:

expression:
	assignment-expression
	expression , assignment-expression

In other words, the comma operator has a lower precedence that even
assignment.

> ... Whatever the merits of 
> defining the grammar in this way, it's not very intuitive; the above 
> suggests that any conditional expression is a form of assignment!

While acknowledging your point, I can't think of a better name to give
that grammar production. Keith has already pointed out the basic problem
by mentioning postfix-expression-or-some-more-primitive-expression as a
more accurate but far clumsier possible replacement to
postfix-expression. Can you suggest an alternative name to give
assignment-expression that correctly describes the current meaning?
-- 
James Kuyper

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

#16492

> OK, so the C standard uses a far more pedantic and unwieldy way of 
> expressing syntax than I would, if it has to enforce each of the 17 
> precedence levels in the grammar!

So given a simple method to unambiguously define precedence with the context 
free grammar, you find it easier to moosh around a lot of ambiguous English. 
Okay. Maybe you should stick to the tutorials and textbools and let the compiler 
folk work with definition.

-- 
My name Indigo Montoya.      |         It's Coraline, not Caroline.
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

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

#16511

"Devil with the China Blue Dress" <chine.bleu@yahoo.com> wrote in message 
news:chine.bleu-8D3DBA.06450531012012@news.eternal-september.org...
>> OK, so the C standard uses a far more pedantic and unwieldy way of
>> expressing syntax than I would, if it has to enforce each of the 17
>> precedence levels in the grammar!
>
> So given a simple method to unambiguously define precedence with the 
> context
> free grammar, you find it easier to moosh around a lot of ambiguous 
> English.
> Okay. Maybe you should stick to the tutorials and textbools and let the 
> compiler
> folk work with definition.

Yet the C standard still seems to need the whole of section 6 to explain, in 
'ambiguous' English, just how the language works. The formal grammar 
obviously isn't sufficient by itself, except to feed to some parser 
generator tools.

Compiler people love their lexer and parser generator tools! Although that 
is the simplest and easiest part of any implementation.

-- 
Bartc 

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

#16548

"BartC" <bc@freeuk.com> writes:
> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
> news:0.d2a24acbe4d003562f6e.20120130214854GMT.8739awsvy1.fsf@bsb.me.uk...
>> "BartC" <bc@freeuk.com> writes:
>
>>> That doesn't make sense at all. The conditional-operator syntax is more
>>> like:
>>>
>>>  expression1 ? expression2 : expression3
>>
>> That's not how syntax is expressed.  You'd need productions for all of
>> expression1, expression2, and expression3.  The C grammar correctly
>> encapsulates what is valid (syntactically) and what it not.
>
> OK, so the C standard uses a far more pedantic and unwieldy way of 
> expressing syntax than I would, if it has to enforce each of the 17 
> precedence levels in the grammar!
>
> (I would write the formal syntax as just:
>
>  expr ? expr : expr
>
> worrying about any restrictions on each expr later, while the production of 
> 'expr' doesn't itself worry about precedence (which would just be an 
> attribute of a binary operator).
>
> I've implemented such a conditional operator for real, using this informal 
> approach, and it works fine. Although I do insist in enclosing the thing in 
> parentheses.)

If you "insist on enclosing the thing in parentheses", then you're
describing a different grammar than the one the C standard describes.

Enforcing the 17 precedence levels by defining them in the grammar makes
some things easier; you don't need another level of logic to resolve
operator precedence.

And I would think that defining every kind of expression as "expr" would
create a lot of cases where an expression can't be parsed unambiguously.

Perhaps your approach is valid, but the one used by the standard is
certainly valid as well.  (Personally I like the standard's approach
better, but that's a matter of opinion.)

[...]

>> assignment-expression:
>>   conditional-expression
>>   unary-expression assignment-operator assignment-expression
>>
>> just says that an assignment expression can be a conditional expression
>> on its own.
>
> You have to look further into the Standard to discover that 
> 'assignment-expression' just means 'any expression'.

So look further into the Standard.

>                                                      Whatever the merits of 
> defining the grammar in this way, it's not very intuitive; the above 
> suggests that any conditional expression is a form of assignment!

As I said in my other response, the names are a little unintuitive
*unless you understand what they really mean*.  Other than radically
changing the way the grammar is defined (would you advocate doing
that?), I can't think of a better way of naming the various productions.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#16549

"BartC" <bc@freeuk.com> writes:
> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.d2a24acbe4d003562f6e.20120130214854GMT.8739awsvy1.fsf@bsb.me.uk...
[...]
>> assignment-expression:
>>   conditional-expression
>>   unary-expression assignment-operator assignment-expression
>>
>> just says that an assignment expression can be a conditional expression
>> on its own.
>
> You have to look further into the Standard to discover that
> assignment-expression' just means 'any expression'. Whatever the
> merits of defining the grammar in this way, it's not very intuitive;
> the above suggests that any conditional expression is a form of
> assignment!

Sorry, I overlooked your error here.  An assignment expression is *not*
just "any expression".  For example, the expression

    x, y

is not an assignment-expression.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#16460

James Kuyper <jameskuyper@verizon.net> writes:

> On 01/30/2012 11:43 AM, BartC wrote:
>> 
>> 
>> "Devil with the China Blue Dress" <chine.bleu@yahoo.com> wrote in message 
>> news:chine.bleu-61D2CA.08302730012012@news.eternal-september.org...
>>> In article <87hazdcikg.fsf@huddi.jernurt.dk>,
>>> Anders Wegge Keller <wegge@wegge.dk> 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;

No, it's a constraint violation.

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

No parentheses are needed.  C parses the original as ((a>b)?a:b) = 42;

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

You've got that the wrong way round.  C++ permits the third operand to
be an assignment expression; C does not.  The upshot is you do need
parentheses in C++ to get what the OP presumably wanted.

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

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

#16433

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

-- 
Tim Prince

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

#16440

On 2012-01-30, timprince <tprince@computer.org> 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.

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

#16436

On 2012-01-30, Anders Wegge Keller <wegge@wegge.dk> 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. 

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.

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

#16447

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2012-01-30, Anders Wegge Keller <wegge@wegge.dk> 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.*

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

#16450

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.

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

#16442

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.

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

#16446

"jacob navia" <jacob@spamsink.net> wrote in message 
news:jg6m3s$1n6$1@speranza.aioe.org...
> 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 

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

#16451

Am 01/30/2012 07:21 PM, schrieb BartC:
> "jacob navia" <jacob@spamsink.net> wrote in message
>> 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!

which were the other three?

Even without forcing them to a particular standard, for me gcc and
clang give the correct diagnostic and refuse to compile it.

Jens

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

#16453

"Jens Gustedt" <jens.gustedt@loria.fr> wrote in message 
news:4F26EC5E.2000402@loria.fr...
> Am 01/30/2012 07:21 PM, schrieb BartC:
>> "jacob navia" <jacob@spamsink.net> wrote in message
>>> 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!
>
> which were the other three?

They were gcc 4.5.0, PellesC, and DigitalMars C.


-- 
Bartc
 

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

#16455

Am 01/30/2012 08:32 PM, schrieb BartC:
> "Jens Gustedt" <jens.gustedt@loria.fr> wrote in message
> news:4F26EC5E.2000402@loria.fr...
>> which were the other three?
> 
> They were gcc 4.5.0, PellesC, and DigitalMars C.

hm strange, I have gcc 4.5.2 (on linux) and it gives me the correct
error report. Somebody in this thread mentioned that the extension to
allow ?: to be an lvalue has been remove with gcc 4.0

Jens

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

#16456

"Jens Gustedt" <jens.gustedt@loria.fr> wrote in message 
news:4F26F71E.6010304@loria.fr...
> Am 01/30/2012 08:32 PM, schrieb BartC:
>> "Jens Gustedt" <jens.gustedt@loria.fr> wrote in message
>> news:4F26EC5E.2000402@loria.fr...
>>> which were the other three?
>>
>> They were gcc 4.5.0, PellesC, and DigitalMars C.
>
> hm strange, I have gcc 4.5.2 (on linux) and it gives me the correct
> error report.

No, gcc was one of the three that didn't work, giving an error report.

When I said lccwin32 worked 'as expected', I meant that it allowed the 
conditional operator on the left of an assignment and worked correctly...

-- 
Bartc 

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

#16458

"BartC" <bc@freeuk.com> writes:
> "Jens Gustedt" <jens.gustedt@loria.fr> wrote in message
> news:4F26F71E.6010304@loria.fr...
>> Am 01/30/2012 08:32 PM, schrieb BartC:
>>> "Jens Gustedt" <jens.gustedt@loria.fr> wrote in message
>>> news:4F26EC5E.2000402@loria.fr...
>>>> which were the other three?
>>>
>>> They were gcc 4.5.0, PellesC, and DigitalMars C.
>>
>> hm strange, I have gcc 4.5.2 (on linux) and it gives me the correct
>> error report.
>
> No, gcc was one of the three that didn't work, giving an error report.
>
> When I said lccwin32 worked 'as expected', I meant that it allowed the
> conditional operator on the left of an assignment and worked
> correctly...

And why would you expect that?  The C standard explicitly states
[*] that the conditional operator does not yield an lvalue, and
that an assignment requires an lvalue as its left operand.

[*] The statement is in a footnote, but the fact that the standard
doesn't say that it *does* yield an lvalue is sufficient.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#16443

Anders Wegge Keller <wegge@wegge.dk> 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.0.4/gcc_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

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web