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 1 of 3  [1] 2 3  Next page →

#16427 — In how many ways should this fail?

 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.

 

-- 
/Wegge

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

[toc] | [next] | [standalone]

#16428

On 01/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.

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.

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

#16429

On 01/30/2012 11:07 AM, James Kuyper wrote:
> On 01/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;
...
>> 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

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

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

#16441

James Kuyper <jameskuyper@verizon.net> 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.

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

#16430

On Jan 30, 3:32 pm, Anders Wegge Keller <we...@wegge.dk> 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);

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.

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

#16439

gwowen <gwowen@gmail.com> writes:

> On Jan 30, 3:32 pm, Anders Wegge Keller <we...@wegge.dk> 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.

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

<snip>

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

-- 
Ben.

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

#16476

On Jan 30, 5:35 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:

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

Oh, quite right. But that's OK - I don't expect my expectations to
match the standard.

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

#16577

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

> gwowen <gwowen@gmail.com> writes:
>
>> On Jan 30, 3:32 pm, Anders Wegge Keller <we...@wegge.dk> 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.
>
> <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;

I've seen this assertion (or a similar one) made in several
posts in this thread.  I will make a different assertion.
The program fragment (written as an expression statement)

   a > b ? a : b = 42;

is a syntax error.  It has no valid parse under the standard
C grammar, any more than

   a + b = c;

does.

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

#16581

"Tim Rentsch" <txr@alumni.caltech.edu> wrote in message 
news:kfnbopjx9sl.fsf@x-alumni2.alumni.caltech.edu...

> The program fragment (written as an expression statement)
>
>   a > b ? a : b = 42;
>
> is a syntax error.  It has no valid parse under the standard
> C grammar, any more than
>
>   a + b = c;

But is it actually reported as a syntax error?

I would suggest this would be a type error rather than syntax (for example 
you can't apply address-of & to the result of a+b).

-- 
Bartc 

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

#16585

On 02/01/2012 07:14 AM, BartC wrote:
> "Tim Rentsch" <txr@alumni.caltech.edu> wrote in message 
> news:kfnbopjx9sl.fsf@x-alumni2.alumni.caltech.edu...
> 
>> The program fragment (written as an expression statement)
>>
>>   a > b ? a : b = 42;
>>
>> is a syntax error.  It has no valid parse under the standard
>> C grammar, any more than
>>
>>   a + b = c;
> 
> But is it actually reported as a syntax error?
> 
> I would suggest this would be a type error rather than syntax (for example 
> you can't apply address-of & to the result of a+b).

As the C standard is currently written, both of these are constraint
violations, but the relevant constraint is not type-based. "An
assignment operator shall have a modifiable lvalue as its left operand."
(6.5.16p1). A modifiable lvalue which had exactly the same type as a+b
would be perfectly acceptable for the left operand.
-- 
James Kuyper

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

#16589

"BartC" <bc@freeuk.com> writes:

> "Tim Rentsch" <txr@alumni.caltech.edu> wrote in message
> news:kfnbopjx9sl.fsf@x-alumni2.alumni.caltech.edu...
>
>> The program fragment (written as an expression statement)
>>
>>   a > b ? a : b = 42;
>>
>> is a syntax error.  It has no valid parse under the standard
>> C grammar, any more than
>>
>>   a + b = c;
>
> But is it actually reported as a syntax error?

No, not by either gcc or clang.  This is one reason I missed the fact
that it's a syntax error (the other being I did not read the grammar!).

But that's OK.  Errors ("constraint violations") need to be reported,
but there's no requirement on exactly how this is done.

> I would suggest this would be a type error rather than syntax (for
> example you can't apply address-of & to the result of a+b).

That's how both clang and gcc decide to do it.  They alter the grammar
and later report a missing lvalue on the left of the assignment.  This
is a risky strategy, since you have to be sure that everything that
you've let though will get caught later.

A little experimenting suggests that both alter the grammar to be:

  assignment-expression:
    conditional-expression
    conditional-expression assignment-operator assignment-expression

rather than

  assignment-expression:
    conditional-expression
    unary-expression assignment-operator assignment-expression

The change permits, on the left of an assignment, expressions with
operators whose "precedence" is between that of the unary operators and
the conditional operator.  I think this is safe because none of these
extra expression forms can be an lvalue, so all of the newly accepted
syntax will be reported later.

-- 
Ben.

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

#16584

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> gwowen <gwowen@gmail.com> writes:
>>
>>> On Jan 30, 3:32 pm, Anders Wegge Keller <we...@wegge.dk> 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.
>>
>> <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;
>
> I've seen this assertion (or a similar one) made in several
> posts in this thread.  I will make a different assertion.
> The program fragment (written as an expression statement)
>
>    a > b ? a : b = 42;
>
> is a syntax error.

And you would be right to make that assertion!  The grammar is indeed
different between C and C++ but in C there is no valid parse for the
above.

-- 
Ben.

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

#16590

On 02/01/2012 07:59 AM, Ben Bacarisse wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
...
>> posts in this thread.  I will make a different assertion.
>> The program fragment (written as an expression statement)
>>
>>    a > b ? a : b = 42;
>>
>> is a syntax error.
> 
> And you would be right to make that assertion!  The grammar is indeed
> different between C and C++ but in C there is no valid parse for the
> above.

Yes there is: ((a>b) ? a : b) = 42. That parse is a constraint
violation, but not a syntax error.
-- 
James Kuyper

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

#16593

James Kuyper <jameskuyper@verizon.net> writes:

> On 02/01/2012 07:59 AM, Ben Bacarisse wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
> ...
>>> posts in this thread.  I will make a different assertion.
>>> The program fragment (written as an expression statement)
>>>
>>>    a > b ? a : b = 42;
>>>
>>> is a syntax error.
>> 
>> And you would be right to make that assertion!  The grammar is indeed
>> different between C and C++ but in C there is no valid parse for the
>> above.
>
> Yes there is: ((a>b) ? a : b) = 42. That parse is a constraint
> violation, but not a syntax error.

assignment-expression:
  conditional-expression
  unary-expression assignment-operator assignment-expression

If 'a > b ? a : b = 42' is to be parsed as an assignment expression,
what precedes the '=' must be produced by unary-expression.  There's no
sequence of productions from unary-expression that can produce
'a > b ? a : b'.

-- 
Ben.

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

#16595

On 02/01/2012 11:40 AM, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
...
>> Yes there is: ((a>b) ? a : b) = 42. That parse is a constraint
>> violation, but not a syntax error.
> 
> assignment-expression:
>   conditional-expression
>   unary-expression assignment-operator assignment-expression

You're right. Sorry - I'm not sure how I reached that conclusion.

You know, there are people who've accused me of thinking I'm infallible.
I can't imagine how they reached that conclusion - I make mistakes like
this constantly.
-- 
James Kuyper

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

#18349

James Kuyper <jameskuyper@verizon.net> writes:

> On 02/01/2012 11:40 AM, Ben Bacarisse wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
> ...
>>> Yes there is: ((a>b) ? a : b) = 42. That parse is a constraint
>>> violation, but not a syntax error.
>> 
>> assignment-expression:
>>   conditional-expression
>>   unary-expression assignment-operator assignment-expression
>
> You're right. Sorry - I'm not sure how I reached that conclusion.
>
> You know, there are people who've accused me of thinking I'm infallible.
> I can't imagine how they reached that conclusion - I make mistakes like
> this constantly.

Could it be because, despite continuing to make them, there is a
tendendency to tune out contrary suggestions rather than further
discussion and re-examination?

(Yes, I'm aware of the irony in my comment.)

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

#16445

gwowen <gwowen@gmail.com> writes:

> On Jan 30, 3:32 pm, Anders Wegge Keller <we...@wegge.dk> 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.*

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

#16431

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;

is standard C and will work on any conforming compiler.

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

#16432

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

-- 
Bartc 

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

#16435

In article <jg6hcq$3mc$1@dont-email.me>, "BartC" <bc@freeuk.com> 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. Doing as you 
> suggest is a bit like writing:

Not all operators that map rvalues to rvalues also map lvalues to lvalues. In 
particular the ?: does not in C; it loads any lvalue operands into rvalues.

> *(&a) = 42;
> 
> instead of a = 42. It shouldn't be necessary and it's less readable.

In a = 42 there is no operator on the left side of = so a yields the lvalue a 
itself.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web