?: as an lvalue

[Rahul]

Hi Everyone,

I have the following piece of code, and i expected an error, however
i don't get an error,

int main()
{
int aa=0,b=0;
1>0?aa:b = 10;
printf("value %d %d\n",aa,b);
return(0);
}

and output is value 0 0

Thanks in advance ! ! !

[Kenny McCormack]

In article <f8**********************************@h11g2000prf. googlegroups.com>,
Rahul <sa*****@yahoo.co.inwrote:

>Hi Everyone,

I have the following piece of code, and i expected an error, however
i don't get an error,

int main()
{
int aa=0,b=0;
1>0?aa:b = 10;
printf("value %d %d\n",aa,b);
return(0);
}

and output is value 0 0

Thanks in advance ! ! !

int main(void) is better
failure to include stdio.h
unnecessarily parenthesizing the return value
failure to indent the return statement properly
meaningless variable names
failure to capitalize "i" in text (e.g., "i don't get an error")
excessive use of exclamation points
improper capitalization of word "everyone"
use of tacky expression "Thanks in advance"

[Richard Heathfield]

Rahul said:

Hi Everyone,

I have the following piece of code, and i expected an error, however
i don't get an error,

int main()
{
int aa=0,b=0;
1>0?aa:b = 10;

This is a syntax error (which therefore requires the implementation to
diagnose it as such). The syntax of the conditional operator is:

conditional-expression:
logical-OR-expression
logical-OR-expression ? expression : conditional-expression

which your code violates.

printf("value %d %d\n",aa,b);
return(0);
}

and output is value 0 0

Thanks in advance ! ! !

Turn up your warning level. Which implementation are you using?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Rahul]

On Mar 30, 5:19 pm, Richard Heathfield <[e-mail]:

Rahul said:

Hi Everyone,

I have the following piece of code, and i expected an error, however
i don't get an error,

int main()
{
int aa=0,b=0;
1>0?aa:b = 10;

This is a syntax error (which therefore requires the implementation to
diagnose it as such). The syntax of the conditional operator is:

conditional-expression:
logical-OR-expression
logical-OR-expression ? expression : conditional-expression

which your code violates.

printf("value %d %d\n",aa,b);
return(0);
}

and output is value 0 0

Thanks in advance ! ! !

Turn up your warning level. Which implementation are you using?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

I tried MS VC++ 8.0...
http://www.dinkumware.com/exam/default.aspx

[Flash Gordon]

Rahul wrote, On 30/03/08 12:05:

Hi Everyone,

I have the following piece of code, and i expected an error, however
i don't get an error,

In that case you need to tell your compiler to act as a C compiler
rather than as an extended-C-like-language compiler.

int main()
{
int aa=0,b=0;
1>0?aa:b = 10;

This is illegal and a C compiler is required to produce a diagnostic
(warning, error or whatever).

printf("value %d %d\n",aa,b);

Not related to your current problem, but you need to include stdio.h to
use printf.

return(0);
}

and output is value 0 0

If you want to do this then a legal way is as follows:
#include <stdio.h>

int main()
{
int aa=0,b=0;
*(1>0?&aa:&b) = 10;
printf("value %d %d\n",aa,b);
return(0);
}
--
Flash Gordon

[Richard Heathfield]

Rahul said:

On Mar 30, 5:19 pm, Richard Heathfield <[e-mail]:

>Rahul said:

Hi Everyone,

I have the following piece of code, and i expected an error, however
i don't get an error,

int main()
{
int aa=0,b=0;
1>0?aa:b = 10;

This is a syntax error (which therefore requires the implementation to
diagnose it as such). The syntax of the conditional operator is:

conditional-expression:
logical-OR-expression
logical-OR-expression ? expression : conditional-expression

which your code violates.

printf("value %d %d\n",aa,b);
return(0);
}

and output is value 0 0

Thanks in advance ! ! !

Turn up your warning level. Which implementation are you using?

I tried MS VC++ 8.0...

I think the switches you'll need for Visual C are -W4 -Za

(-W4 turns the warning level up as far as it'll go - unless they've added
another level in the last few years - and -Za switches off Microsoft
extensions.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Andrey Tarasevich]

Rahul wrote:

I tried MS VC++ 8.0...

I tried the same compiler and got essentially the same error, saying that left
operand must be a lvalue.

http://www.dinkumware.com/exam/default.aspx

If you tried it at this link, then most likely your code was compiled as C++. In
C++ it would be parsed as '1 0 ? aa : (b = 10)'. Additionally in C++ the
result of ?: can be lvalue. It is not surprise that you didn't get an error.

--
Best regards,
Andrey Tarasevich

[Richard Heathfield]

Flash Gordon said:

Rahul wrote, On 30/03/08 12:05:

>Hi Everyone,

I have the following piece of code, and i expected an error, however
i don't get an error,

In that case you need to tell your compiler to act as a C compiler
rather than as an extended-C-like-language compiler.

The OP is using http://www.dinkumware.com/exam/default.aspx to test his
code. When I present that site with the following source:

#include <stdio.h>

int main(void)
{
int a = 0;
int b = 0;

1 0 ? a : b = 10;

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

return 0;
}

and select the only C option I can find, which is the EDG C99 option, I get
no diagnostic messages whatsoever (unless you count "Code compiled
successfully!" as a diagnostic message).

Either this is a bug in EDG's compiler, or the rules changed in C99. I can
find no evidence of a rule change in C99.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Dave Hansen]

On Mar 30, 7:19 am, Richard Heathfield <[e-mail]:

Rahul said:

Hi Everyone,

I have the following piece of code, and i expected an error, however
i don't get an error,

int main()
{
int aa=0,b=0;
1>0?aa:b = 10;

This is a syntax error (which therefore requires the implementation to
diagnose it as such). The syntax of the conditional operator is:

I believe the syntax is legal. It just doesn't do what the OP wanted
it to.

Consider that it parses as

(1>0)?(aa):(b=10);

Change it to 1<0?aa:b=10; and see the result...

Regards,

-=Dave

[Eric Sosman]

Dave Hansen wrote:

On Mar 30, 7:19 am, Richard Heathfield <[e-mail]:

>Rahul said:

>>Hi Everyone,
I have the following piece of code, and i expected an error, however
i don't get an error,
int main()
{
int aa=0,b=0;
1>0?aa:b = 10;

This is a syntax error (which therefore requires the implementation to
diagnose it as such). The syntax of the conditional operator is:

I believe the syntax is legal. It just doesn't do what the OP wanted
it to.

Consider that it parses as

(1>0)?(aa):(b=10);

Would you care to place a small wager on that?

You could refer to the formal grammar in the Standard
to settle the question, or you could ask informally which
of = and ?: "binds more tightly." The parse you suggest
would follow if = binds more tightly, in which case

x = a ? b : c;

would parse as

(x = a) ? b : c;

Since we know that it actually parses as

x = (a ? b : c);

you may be about to lose some money ...

--
Er*********@sun.com

[Andrey Tarasevich]

Richard wrote:

...
But (c?x:y)=v;
I dont really know what to say.

Is there any reason why you believe that the property of "being an
lvalue" should be necessarily lost in the process of selection from two
lvalues of the same type?

I mean I'm OK personally with the way it works in C. I just like to know
what is it exactly in '(c?x:y)=v' that triggers a "I don't really know
what to say" reaction from some people.

--
Best regards,
Andrey Tarasevich

[Richard]

Andrey Tarasevich <an**************@hotmail.comwrites:

Richard wrote:

>...
But (c?x:y)=v;
I dont really know what to say.

Is there any reason why you believe that the property of "being an
lvalue" should be necessarily lost in the process of selection from
two lvalues of the same type?

I mean I'm OK personally with the way it works in C. I just like to
know what is it exactly in '(c?x:y)=v' that triggers a "I don't really
know what to say" reaction from some people.

because its not a macro? it returns a value. I dont know the legalise
words but it seems "obvious" enough to me, but again it might be because
I am tainted.

[Willem]

Eric wrote:
) Dave Hansen wrote:
)Consider that it parses as
)>
) (1>0)?(aa):(b=10);
)
) Would you care to place a small wager on that?
)
) You could refer to the formal grammar in the Standard
) to settle the question, or you could ask informally which
) of = and ?: "binds more tightly." The parse you suggest
) would follow if = binds more tightly, in which case

Technically, it would also follow if = binds equally tightly.
Left-to-right and all that.

) x = a ? b : c;
)
) would parse as
)
) (x = a) ? b : c;

Again, purely technically, it would not if = were to bind equally tightly.

) Since we know that it actually parses as
)
) x = (a ? b : c);
)
) you may be about to lose some money ...

I'm not going to bet on it though.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[Willem]

Andrey wrote:
) Richard wrote:
) ...
)But (c?x:y)=v;
)I dont really know what to say.
)
) Is there any reason why you believe that the property of "being an
) lvalue" should be necessarily lost in the process of selection from two
) lvalues of the same type?
)
) I mean I'm OK personally with the way it works in C. I just like to know
) what is it exactly in '(c?x:y)=v' that triggers a "I don't really know
) what to say" reaction from some people.

Well then why not also make it possible for functions (that return
pointers) to be lvalues ?

returnspointertostruct(foo)->bar = baz;

Or is that already legal ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[Andrey Tarasevich]

Richard wrote:

>...
I mean I'm OK personally with the way it works in C. I just like to
know what is it exactly in '(c?x:y)=v' that triggers a "I don't really
know what to say" reaction from some people.

because its not a macro? it returns a value. I dont know the legalise
words but it seems "obvious" enough to me, but again it might be because
I am tainted.

Well, unary '*' operator is also not a macro. Yet it evaluates to an
lvalue. Same for '[]' operator (by definition). Do you find this strange
as well?

--
Best regards,
Andrey Tarasevich

[Richard Tobin]

In article <fs**********@registered.motzarella.org>,
Richard <de***@gmail.comwrote:

>I mean I'm OK personally with the way it works in C. I just like to
know what is it exactly in '(c?x:y)=v' that triggers a "I don't really
know what to say" reaction from some people.

>because its not a macro? it returns a value. I dont know the legalise
words but it seems "obvious" enough to me, but again it might be because
I am tainted.

Some other languages allow this. For example, I think Algol 68 allows

IF a THEN b ELSE c FI := d;

In C the number of contexts where an lvalue doesn't decay into an rvalue
is very small, but I don't see anything inherently un-C-like about this
case.

-- Richard

--
:wq

[Richard]

Andrey Tarasevich <an**************@hotmail.comwrites:

Richard wrote:

>>...
I mean I'm OK personally with the way it works in C. I just like to
know what is it exactly in '(c?x:y)=v' that triggers a "I don't really
know what to say" reaction from some people.

because its not a macro? it returns a value. I dont know the legalise
words but it seems "obvious" enough to me, but again it might be because
I am tainted.

Well, unary '*' operator is also not a macro. Yet it evaluates to an
lvalue. Same for '[]' operator (by definition). Do you find this
strange as well?

I think you have lost the track with all due respect. His original did
produce an lvalue but a value.

The "*" made it then an lvalue in the other case.

I dont really know what we are aguing.

There appears to be some sort of push for ?: to return an lvalue but it
doesnt and never did.

[Richard]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <fs**********@registered.motzarella.org>,
Richard <de***@gmail.comwrote:

>>I mean I'm OK personally with the way it works in C. I just like to
know what is it exactly in '(c?x:y)=v' that triggers a "I don't really
know what to say" reaction from some people.

>>because its not a macro? it returns a value. I dont know the legalise
words but it seems "obvious" enough to me, but again it might be because
I am tainted.

Some other languages allow this. For example, I think Algol 68 allows

IF a THEN b ELSE c FI := d;

In C the number of contexts where an lvalue doesn't decay into an rvalue
is very small, but I don't see anything inherently un-C-like about this
case.

-- Richard

And he can do it in C using pointers and *. I dont see the problem or
the confusion here as far as the C language goes to be honest.

[Richard Tobin]

In article <fs**********@registered.motzarella.org>,
Richard <de***@gmail.comwrote:

>Well, unary '*' operator is also not a macro. Yet it evaluates to an
lvalue. Same for '[]' operator (by definition). Do you find this
strange as well?

>I think you have lost the track with all due respect. His original did
produce an lvalue but a value.

I think the point was that * is an example of an operator that produces
an lvalue, so it's not necessarily unreasonable for the ?: operator to.

-- Richard
--
:wq

[Andrey Tarasevich]

Richard wrote:

>Richard wrote:

>>>...
I mean I'm OK personally with the way it works in C. I just like to
know what is it exactly in '(c?x:y)=v' that triggers a "I don't really
know what to say" reaction from some people.
because its not a macro? it returns a value. I dont know the legalise
words but it seems "obvious" enough to me, but again it might be because
I am tainted.

Well, unary '*' operator is also not a macro. Yet it evaluates to an
lvalue. Same for '[]' operator (by definition). Do you find this
strange as well?

I think you have lost the track with all due respect. His original did
produce an lvalue but a value.

The "*" made it then an lvalue in the other case.

I dont really know what we are aguing.

I'm not really arguing. The way I interpreted your responses, it seemed
that when someone said that in C++ '?:' would return an lvalue in this
case, you essentially made it clear that you find it unnatural and/or
illogical (again, the way I interpreted your responses). I just want to
know what is it exactly that you find unnatural and/or illogical.

--
Best regards,
Andrey Tarasevich

[Willem]

Richard Tobias wrote:
) In article <fs**********@registered.motzarella.org>,
) Richard <de***@gmail.comwrote:
)>I think you have lost the track with all due respect. His original did
)>produce an lvalue but a value.
)
) I think the point was that * is an example of an operator that produces
) an lvalue, so it's not necessarily unreasonable for the ?: operator to.

Yes, but * _always_ produces lvalues.

If the ?: operator were to produce lvalues, it can only do so sometimes,
which makes it a lot more difficult to do so.

I think this argument has already been made crossthread, by the way.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[Richard]

Andrey Tarasevich <an**************@hotmail.comwrites:

Richard wrote:

>>Richard wrote:
...
I mean I'm OK personally with the way it works in C. I just like to
know what is it exactly in '(c?x:y)=v' that triggers a "I don't really
know what to say" reaction from some people.
because its not a macro? it returns a value. I dont know the legalise
words but it seems "obvious" enough to me, but again it might be because
I am tainted.
Well, unary '*' operator is also not a macro. Yet it evaluates to an
lvalue. Same for '[]' operator (by definition). Do you find this
strange as well?

I think you have lost the track with all due respect. His original did
produce an lvalue but a value.

The "*" made it then an lvalue in the other case.

I dont really know what we are aguing.

I'm not really arguing. The way I interpreted your responses, it
seemed that when someone said that in C++ '?:' would return an lvalue
in this case, you essentially made it clear that you find it unnatural
and/or illogical (again, the way I interpreted your responses). I just
want to know what is it exactly that you find unnatural and/or
illogical.

Firstly I wasnt aware of any C++ talk.

Secondly, I find it unnatural because it is a special operator which,
well, does not return an lvalue. Sure, I'm only arguing for "what it
is". When someone claims "this makes perfect" sense and it does not make
any sense at all in the context of the language being discussed then I
think thats a fair response.

[Andrey Tarasevich]

la************@siemens.com wrote:

...
Because b and c are two distinct objects that can have different types,
which makes the type of any resulting lvalue somewhat problematic.
...

Yes, it does. But when the second and the third operand have different
(more precisely: non-compatible) types, there are quite a few things
related to '?:' that are "problematic". The "lvalue" issue is just one
of them. I we approach all of these issues with the same degree of
pessimism, then we should probably prohibit '?:' operator entirely.

A more concrete example: in C language the '?:' operator can be applied
to structures and unions. Of course, it is required that the second and
the third operand have the same type (more precisely: compatible types).
Needless to say, even though the result is not an lvalue, the idea to
allow '?:' with structures immediately runs into the very same
type-compatibility issues you are referring to. Still, it is perfectly
legal in C to apply '?:' to structures. This illustrates the fact that
in the process of language evolution the type-compatibility issue in
'?:' has not been seen as a reason to discard a feature.

--
Best regards,
Andrey Tarasevich

[Philip Potter]

Flash Gordon wrote:

Bartc wrote, On 31/03/08 18:45:

[discussion of ?: as an lvalue compared to other lvalue expressions]

>a: You can write a = x without writing *(&a) = x

You can't do 3 = x

>a.b: You can write a.b = x without writing *(&a + offsetof b) = x

You can't do 5.b or a.5

But you can do f().b
E1.E2 is only an lvalue if E1 is an lvalue.

I think you are wrong. Look at the fact that all of the other operators
you mention *require* at least one of the operands to be an object but
neither + nor ?: require and operand to be an object. Then you should
see why it is natural for a?b:c = x to be wrong.

The member access operator . does not require either operand to be an
lvalue; if its first operand is not an lvalue, then the resultant
expression is not an lvalue. This is very similar to the C++ behaviour
of ?: - if both result expressions are lvalues, the overall expression
is an lvalue, otherwise it is not.

I'm not advocating the C++ way, just showing that it is reasonable. I
couldn't care less whether ?: was allowed to be an lvalue or not, but
I'd probably never use it in my code.

Philip

[Bartc]

"Philip Potter" <pg*@doc.ic.ac.ukwrote in message
news:fs**********@aioe.org...

Flash Gordon wrote:

>Bartc wrote, On 31/03/08 18:45:

[discussion of ?: as an lvalue compared to other lvalue expressions]

>>a: You can write a = x without writing *(&a) = x

You can't do 3 = x

>>a.b: You can write a.b = x without writing *(&a + offsetof b) = x

You can't do 5.b or a.5

But you can do f().b
E1.E2 is only an lvalue if E1 is an lvalue.

Well f().b = x would be an error too. I was pointing out that where a.b=x is
legal, you can write it without all this *(&a+offsetof business, because
compiler magic is being applied.

>

>I think you are wrong. Look at the fact that all of the other operators
you mention *require* at least one of the operands to be an object but
neither + nor ?: require and operand to be an object. Then you should see
why it is natural for a?b:c = x to be wrong.

The member access operator . does not require either operand to be an
lvalue; if its first operand is not an lvalue, then the resultant
expression is not an lvalue. This is very similar to the C++ behaviour of
?: - if both result expressions are lvalues, the overall expression is an
lvalue, otherwise it is not.

I'm not advocating the C++ way, just showing that it is reasonable. I
couldn't care less whether ?: was allowed to be an lvalue or not, but I'd
probably never use it in my code.

I don't think it's that difficult to find uses; the following code uses it
with ++. C does allow this, but the expression needs 'decorating' with
*(&&), although the brackets are advisable here:

#include <stdio.h>
#include <stdlib.h>

int main()
{
int odd=0,even=0;
int i;

for (i=0;i<10000000;++i)
++*(rand()&1 ? &odd : &even);

printf("Odd ratio = %f%%\n",100.0*(double)odd/(double)(odd+even));
}

--
Bart

[Philip Potter]

Bartc wrote:

"Philip Potter" <pg*@doc.ic.ac.ukwrote in message
news:fs**********@aioe.org...

>Flash Gordon wrote:

>>Bartc wrote, On 31/03/08 18:45:

[discussion of ?: as an lvalue compared to other lvalue expressions]

>>>a: You can write a = x without writing *(&a) = x
You can't do 3 = x

a.b: You can write a.b = x without writing *(&a + offsetof b) = x
You can't do 5.b or a.5

But you can do f().b
E1.E2 is only an lvalue if E1 is an lvalue.

Well f().b = x would be an error too. I was pointing out that where a.b=x is
legal, you can write it without all this *(&a+offsetof business, because
compiler magic is being applied.

That's exactly the point I was making too. I was saying that a.b is
conditionally an lvalue based on a, so why not have a?b:c conditionally
an lvalue based on b and c?

>I
couldn't care less whether ?: was allowed to be an lvalue or not, but I'd
probably never use it in my code.

I don't think it's that difficult to find uses; the following code uses it
with ++.

[snip code]

I don't argue that it's impossible to find situations in which case it
could be used, but I wouldn't ever consider it the preferred construct.
It's a style thing.

[Willem]

Philip wrote:
) That's exactly the point I was making too. I was saying that a.b is
) conditionally an lvalue based on a, so why not have a?b:c conditionally
) an lvalue based on b and c?

Correct me if I'm wrong, but isn't a.b *always* an lvalue in C ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[Richard]

Willem <wi****@stack.nlwrites:

Philip wrote:
) That's exactly the point I was making too. I was saying that a.b is
) conditionally an lvalue based on a, so why not have a?b:c conditionally
) an lvalue based on b and c?

Correct me if I'm wrong, but isn't a.b *always* an lvalue in C ?

No. Not always :-;

e.g

c = a.b;

Here it is an rvalue ....

>
SaSW, Willem

[Ben Bacarisse]

Philip Potter <pg*@doc.ic.ac.ukwrites:

Willem wrote:

<snip>

>Correct me if I'm wrong, but isn't a.b *always* an lvalue in C ?

You are wrong according to n1256 6.5.2.3p3:

<snip>

struct a { int b; } inst_a;
struct a f(void) { inst_a.b = 0; return inst_a; }
int main(void) {
f().b = 10; /* error - f().b is not an lvalue */
return f().b; /* okay - f().b is an rvalue */
}

I like your example better than mine.

--
Ben.

[Ben Bacarisse]

Richard <de***@gmail.comwrites:
<snip>

I can see that my little bit humour based on usual c.l.c pedantry was
lost. I even added the ":-;" to make it clear. Oh well. Sorry.

Would it be too pedantic to say that :-; is hardly a well recognised
emoticon. My news readers renders most, but that one is just too
bizarre. I thought it was just a typo for your punctuation
introducing an example. The lamer the joke, the more important the
smiley that flags it...

--
Ben.

[Ben Bacarisse]

Richard <de***@gmail.comwrites:

Ben Bacarisse <be********@bsb.me.ukwrites:

>Richard <de***@gmail.comwrites:
<snip>

>>I can see that my little bit humour based on usual c.l.c pedantry was
lost. I even added the ":-;" to make it clear. Oh well. Sorry.

Would it be too pedantic to say that :-; is hardly a well recognised

Then you live on another planet? (obligatory ":-)"). Was it you who
also claimed he did not recognise the word "nOOb"? Not that I dont
believe you - I just find it VERY hard to believe that, hate them as
some do, you are not aware of such commonly used shortcuts.

You do love to invent your corespondents' views don't you?

It is one of the most common used "smileys". It is a winking smile.

You still don't see the mistake you've made? I think a ;-) is called for!

--
Ben.

[lawrence.jones]

Andrey Tarasevich <an**************@hotmail.comwrote:

>
What it illustrates is that the type-compatibility requirements are
_already_ in the language. They are already there and there's no way
around them. The fact that '?:' returns a non-lvalue in C doesn't really
make things easier. And making '?:' return an lvalue wouldn't really
make things harder.

But there's no general requirement that the second and third argument
have compatible type; the requirement is indirect and only applies in
certain contexts. For example:

int i = 0;
double d = 1.0;

1 < 0 ? d : i;

is perfectly valid even though d and i do not have compatible type.

And I don't think compatible types is sufficiently strong, I think they
would have to be identical (which is what C++ requires, I believe).

-Larry Jones

I like maxims that don't encourage behavior modification. -- Calvin

[lawrence.jones]

Ben Bacarisse <be********@bsb.me.ukwrote:

>
I suspect it is more likely to have been a case of there being no
strong reason to alter existing practice, rather than there being some
killer technical reason why it is too hard or does not fit with C's
view of the world.

Exactly. I'd be curious to know what it was that persuaded C++ to alter
existing practice.

-Larry Jones

I told her to expect you to deny everything. -- Calvin

[Harald van =?UTF-8?b?RMSzaw==?=]

On Tue, 01 Apr 2008 12:09:00 -0400, lawrence.jones wrote:

Andrey Tarasevich <an**************@hotmail.comwrote:

>What it illustrates is that the type-compatibility requirements are
_already_ in the language. They are already there and there's no way
around them. The fact that '?:' returns a non-lvalue in C doesn't
really make things easier. And making '?:' return an lvalue wouldn't
really make things harder.

But there's no general requirement that the second and third argument
have compatible type; the requirement is indirect and only applies in
certain contexts. For example:

int i = 0;
double d = 1.0;

1 < 0 ? d : i;

is perfectly valid even though d and i do not have compatible type.

And I don't think compatible types is sufficiently strong, I think they
would have to be identical (which is what C++ requires, I believe).

void (*fp1)();
void (*fp2)(void);
void g(void) {
(rand() ? fp1 : fp2) = g;
}
void h(void) {
extern void (*fp1)(void);
(rand() ? fp1 : fp2) = g;
}

Okay, in C++, fp1 and fp2 are identical types, but if C were extended to
allow use of ?:'s result as an lvalue, it looks a bit silly to allow h
but not g.

Allowing ?: to be used as an lvalue could break code, by the way:
currently,

volatile int i;
volatile int j;
rand() ? i : j;

causes a read of both i and j, while this would change to read only one
of them.

[santosh]

Richard wrote:

>
Ben Bacarisse <be********@bsb.me.ukwrites:

>Richard <de***@gmail.comwrites:
<snip>

>>I can see that my little bit humour based on usual c.l.c pedantry
was lost. I even added the ":-;" to make it clear. Oh well. Sorry.

Would it be too pedantic to say that :-; is hardly a well recognised

Then you live on another planet? (obligatory ":-)"). Was it you who
also claimed he did not recognise the word "nOOb"? Not that I dont
believe you - I just find it VERY hard to believe that, hate them as
some do, you are not aware of such commonly used shortcuts.

>emoticon. My news readers renders most, but that one is just too
bizarre. I thought it was just a typo for your punctuation
introducing an example. The lamer the joke, the more important the
smiley that flags it...

It is one of the most common used "smileys". It is a winking smile.

Shouldn't a winking smile be ;-) ?

[lawrence.jones]

Philip Potter <pg*@doc.ic.ac.ukwrote:

>
I didn't notice the change bar. What exactly do the change bars mean? Is
it everything which has changed since C99, or n1124, or what?

Everything since C99.

-Larry Jones

Summer vacation started! I can't be sick! -- Calvin

[Andrey Tarasevich]

Willem wrote:

Philip wrote:
) That's exactly the point I was making too. I was saying that a.b is
) conditionally an lvalue based on a, so why not have a?b:c conditionally
) an lvalue based on b and c?

Correct me if I'm wrong, but isn't a.b *always* an lvalue in C ?

No. It is only lvalue when 'a' itself is an lvalue.

--
Best regards,
Andrey Tarasevich

[Flash Gordon]

Philip Potter wrote, On 01/04/08 13:15:

Bartc wrote:

>"Philip Potter" <pg*@doc.ic.ac.ukwrote in message
news:fs**********@aioe.org...

>>Flash Gordon wrote:
Bartc wrote, On 31/03/08 18:45:
[discussion of ?: as an lvalue compared to other lvalue expressions]
a: You can write a = x without writing *(&a) = x
You can't do 3 = x

a.b: You can write a.b = x without writing *(&a + offsetof b) = x
You can't do 5.b or a.5
But you can do f().b
E1.E2 is only an lvalue if E1 is an lvalue.

Well f().b = x would be an error too. I was pointing out that where
a.b=x is legal, you can write it without all this *(&a+offsetof
business, because compiler magic is being applied.

That's exactly the point I was making too. I was saying that a.b is
conditionally an lvalue based on a,

Well, since that is a post C99 change to the language I'm sure you can
forgive some people for forgetting it.

Also, remember that the original decision was made before C89 was
published (either in the standardisation process or earlier) so the fact
that the . operator now conditionally produces an lvalue would not have
impinged on anyone's thought processes back then.

I suspect with C99 no one even thought about it rather than the
committee thinking about it and rejecting the idea.

so why not have a?b:c conditionally
an lvalue based on b and c?

<snip>

I agree it could be done. I also don't have any objection to the
standard being changed to allow it.
--
Flash Gordon

[lawrence.jones]

Harald van D??k <tr*****@gmail.comwrote:

>
Allowing ?: to be used as an lvalue could break code, by the way:
currently,

volatile int i;
volatile int j;
rand() ? i : j;

causes a read of both i and j, while this would change to read only one
of them.

Huh? The definition of ?: currently says that only one of the second
and third operands are evaluated, so either i or j is evaluated but not
both, so only one is read.

-Larry Jones

I'm getting disillusioned with these New Years. -- Calvin

[Ben Bacarisse]

Flash Gordon <sp**@flash-gordon.me.ukwrites:

Philip Potter wrote, On 01/04/08 13:15:

>Bartc wrote:

>>"Philip Potter" <pg*@doc.ic.ac.ukwrote in message
news:fs**********@aioe.org...
Flash Gordon wrote:
Bartc wrote, On 31/03/08 18:45:
[discussion of ?: as an lvalue compared to other lvalue expressions]
>a: You can write a = x without writing *(&a) = x
You can't do 3 = x
>
>a.b: You can write a.b = x without writing *(&a + offsetof b) = x
You can't do 5.b or a.5
But you can do f().b
E1.E2 is only an lvalue if E1 is an lvalue.

Well f().b = x would be an error too. I was pointing out that where
a.b=x is legal, you can write it without all this *(&a+offsetof
business, because compiler magic is being applied.

That's exactly the point I was making too. I was saying that a.b is
conditionally an lvalue based on a,

Well, since that is a post C99 change to the language I'm sure you can
forgive some people for forgetting it.

There is almost identical wording in my text-only version of C90. I
don't think the idea is a new one.

--
Ben.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Tue, 01 Apr 2008 16:51:30 -0400, lawrence.jones wrote:

Harald van D??k <tr*****@gmail.comwrote:

>>
Allowing ?: to be used as an lvalue could break code, by the way:
currently,

volatile int i;
volatile int j;
rand() ? i : j;

causes a read of both i and j, while this would change to read only one
of them.

Huh? The definition of ?: currently says that only one of the second
and third operands are evaluated, so either i or j is evaluated but not
both, so only one is read.

Oh dear. Firstly, I meant that it would change to read none instead of
one, and secondly, I was wrong about that anyway, because I was thinking
of C++ rules where lvalue to value conversion does not happen in
expression statements.

[Andrey Tarasevich]

Ben Bacarisse wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrites:

>Philip Potter wrote, On 01/04/08 13:15:

>>Bartc wrote:
"Philip Potter" <pg*@doc.ic.ac.ukwrote in message
news:fs**********@aioe.org...
Flash Gordon wrote:
>Bartc wrote, On 31/03/08 18:45:
[discussion of ?: as an lvalue compared to other lvalue expressions]
>>a: You can write a = x without writing *(&a) = x
>You can't do 3 = x
>>
>>a.b: You can write a.b = x without writing *(&a + offsetof b) = x
>You can't do 5.b or a.5
But you can do f().b
E1.E2 is only an lvalue if E1 is an lvalue.
Well f().b = x would be an error too. I was pointing out that where
a.b=x is legal, you can write it without all this *(&a+offsetof
business, because compiler magic is being applied.
That's exactly the point I was making too. I was saying that a.b is
conditionally an lvalue based on a,

Well, since that is a post C99 change to the language I'm sure you can
forgive some people for forgetting it.

There is almost identical wording in my text-only version of C90. I
don't think the idea is a new one.

There's no difference between C89/90 and C99 in this regard.

The only semi-relevant difference there one can find is related to the
handling of arrays. In C89/90 it was illegal to do this

struct S { int a[10]; } foo(void);
...
foo().a[1]; // error in C89/90

because in C89/90 array-to-pointer conversion (essential to the
semantics of '[]') was not allowed for non-lvalue arrays.

In C99 array-to-pointer conversion is applied to non-lvalue arrays,
meaning that the above code becomes legal. An interesting side effect of
this change is that in C99 the following is legal as well

foo().a[1] = 5;

--
Best regards,
Andrey Tarasevich

[Harald van =?UTF-8?b?RMSzaw==?=]

On Tue, 01 Apr 2008 20:49:14 -0700, Andrey Tarasevich wrote:

struct S { int a[10]; } foo(void);
...
foo().a[1]; // error in C89/90
[...]
In C99 array-to-pointer conversion is applied to non-lvalue arrays,
meaning that the above code becomes legal. An interesting side effect of
this change is that in C99 the following is legal as well

foo().a[1] = 5;

In C99, this violates no constraints, but if it is executed, the
behaviour is undefined. And unfortunately, even if you do what you can to
get a notice from compilers:

const struct S { int a[10]; } foo(void);
foo().a[1] = 5;

still no constraints are violated.

[Flash Gordon]

Ben Bacarisse wrote, On 02/04/08 00:40:

Flash Gordon <sp**@flash-gordon.me.ukwrites:

>Philip Potter wrote, On 01/04/08 13:15:

>>Bartc wrote:
"Philip Potter" <pg*@doc.ic.ac.ukwrote in message
news:fs**********@aioe.org...
Flash Gordon wrote:
>Bartc wrote, On 31/03/08 18:45:
[discussion of ?: as an lvalue compared to other lvalue expressions]
>>a: You can write a = x without writing *(&a) = x
>You can't do 3 = x
>>
>>a.b: You can write a.b = x without writing *(&a + offsetof b) = x
>You can't do 5.b or a.5
But you can do f().b
E1.E2 is only an lvalue if E1 is an lvalue.
Well f().b = x would be an error too. I was pointing out that where
a.b=x is legal, you can write it without all this *(&a+offsetof
business, because compiler magic is being applied.
That's exactly the point I was making too. I was saying that a.b is
conditionally an lvalue based on a,

Well, since that is a post C99 change to the language I'm sure you can
forgive some people for forgetting it.

There is almost identical wording in my text-only version of C90. I
don't think the idea is a new one.

Ah well, put it down to the fact I've never considered using the .
operator without the left operand being an lvalue.
--
Flash Gordon

[lawrence.jones]

Andrey Tarasevich <an**************@hotmail.comwrote:

>
In C99 array-to-pointer conversion is applied to non-lvalue arrays,
meaning that the above code becomes legal. An interesting side effect of
this change is that in C99 the following is legal as well

foo().a[1] = 5;

No, it's not:

If an attempt is made to modify the result of a function call or
to access it after the next sequence point, the behavior is
undefined.

-Larry Jones

My brain is trying to kill me. -- Calvin

[Keith Thompson]

la************@siemens.com writes:

Andrey Tarasevich <an**************@hotmail.comwrote:

>In C99 array-to-pointer conversion is applied to non-lvalue arrays,
meaning that the above code becomes legal. An interesting side effect of
this change is that in C99 the following is legal as well

foo().a[1] = 5;

No, it's not:

If an attempt is made to modify the result of a function call or
to access it after the next sequence point, the behavior is
undefined.

Undefined behavior is illegal?

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[lawrence.jones]

Keith Thompson <ks***@mib.orgwrote:

>
Undefined behavior is illegal?

Well, the C Police aren't going to come and arrest you, but it's not
valid, which is what most people mean by "legal".

-Larry Jones

Hmm... That might not be politic. -- Calvin

[Harald van =?UTF-8?b?RMSzaw==?=]

On Wed, 02 Apr 2008 15:39:32 -0400, lawrence.jones wrote:

Keith Thompson <ks***@mib.orgwrote:

>Undefined behavior is illegal?

Well, the C Police aren't going to come and arrest you, but it's not
valid, which is what most people mean by "legal".

Most people don't consider the things illegal that the police turn a
blind eye towards. Undefined behaviour is what happens when your program
doesn't play by C's rules, but at the same time, C's rules tell your
compiler not to arrest you.

[Wolfgang Draxinger]

Aside the suggestion already made

*(a ? &b : &c) = d;

I'd like to know if this would be as valid, or to be more
precisely, does the conditional operator guarantee, that only
the selected expression is actually evaluated.

a ? (b=d) : (c=d);

I'm too lazy to look in the standard now, but common sense tells
me, that only evaluation of the selected expression must take
place, since functions might be called, that change the global
state of the program. And in case of pointer:

int *p; /*something_usefull or NULL*/
int a;
p != NULL ? a = *p : a = -1;

Any preconditional evaluation might end up in a segmentation
violation.

Wolfgang Draxinger
--
E-Mail address works, Jabber: he******@jabber.org, ICQ: 134682867

[Ben Pfaff]

Wolfgang Draxinger <wd********@darkstargames.dewrites:

I'd like to know if this would be as valid, or to be more
precisely, does the conditional operator guarantee, that only
the selected expression is actually evaluated.

a ? (b=d) : (c=d);

Yes and yes.
--
Ben Pfaff
http://benpfaff.org