Return value of assignment operator

[Sac]

Hello C Gurus,

Does the " = " operator return assigned value?
Following printf prints 3.
printf("X=%d",(x=3));
Does this print value of x or value returned by '"="
operator?

Thanks
Sachin

 

[Fred]

Hello C Gurus,

         Does the " = " operator return assigned value?
         Following printf prints 3.
         printf("X=%d",(x=3));
         Does this print value of x or value returned by '"="
operator?

Seems like a pretty simple thing to investigate yourself and find out
what it prints. (It does print the value of x; you just need to figure
out whether it is its value before or after the assignment)

 

[exallion.long]

Hello C Gurus,

         Does the " = " operator return assigned value?
         Following printf prints 3.
         printf("X=%d",(x=3));
         Does this print value of x or value returned by '"="
operator?

Thanks
Sachin

in this case it will return value of x,value of x will be affected
before.
i don't think the operator can return a value.

 

[Ben Bacarisse]

Seems like a pretty simple thing to investigate yourself and find out
what it prints.

In general that is not a very good way to answer C questions.
Implementations are permitted to do some things that are not mandated
so you might end up relying on something arbitrary.

(It does print the value of x; you just need to figure
out whether it is its value before or after the assignment)

The fact the you get "3" does not tell you if it is printing the value
of the left hand side or the right hand side. For example, given

unsigned int x = 0;

is the value of x = -1 negative?

(Answer: no. The value of x = E has the type and value of x after the
assignment -- but it is not an lvalue).

 

[jameskuyper]

The 2nd argument to the printf() call is the assignment expression
"x=3". It is the value of that expression which gets passed to printf
(), not 'x' itself. Of course, it's hard to determine this by any
method other than reading the C standard. That's because there's a
sequence point separating the evaluation of a function argument from
the execution of the function itself, so 'x' will already have the
same value as the expression 'x=3' by the time printf() executes.

in this case it will return value of x,value of x will be affected
before.
i don't think the operator can return a value.

Operators (or more accurately, expressions that contain an operator)
normally return a value, and assignment expressions are no exception
to that rule. Changing the value of 'x' is described by the C standard
as a side-effect - of course, that side-effect is usually the entire
reason for using an assignment expression, but it's still "just" a
side-effect as far as the standard is concerned.

 

[Kenny McCormack]

Not quite. The 2nd argument to the printf() call is the
parenthesized expression `(x=3)', a different syntactic
category from an assignment expression. The parenthesized
expression has the same type and value as the parenthesized
assignment expression `x=3'. But the argument is strictly
a parenthesized expression, not an assignment expression.

A subtle distinction, to be sure.

Yours,
Han from China

Seems like you've caught the "infinite reducibility" bug.

Treatment is available.

 

[Keith Thompson]

(e-mail address removed) wrote: [...]

i don't think the operator can return a value.

Operators (or more accurately, expressions that contain an operator)
normally return a value, and assignment expressions are no exception
to that rule. Changing the value of 'x' is described by the C standard
as a side-effect - of course, that side-effect is usually the entire
reason for using an assignment expression, but it's still "just" a
side-effect as far as the standard is concerned.

A quibble about terminology:

Functions *return* values. Expressions *yield* values.

It's nearly the same thing, and it wouldn't be a tragedy if we used
the same word for both, but I find it helpful to keep the two concepts
distinct. Note that the editor of n1256.pdf (C99 with the three
Technical Corrigenda merged in) went through and changed the wording
to use "yield" consistently for the results of expressions.

 

[Andrey Tarasevich]

Does the " = " operator return assigned value?
Following printf prints 3.
printf("X=%d",(x=3));
Does this print value of x or value returned by '"="
operator?

It prints the result of 'x=3' expression, which is the "value returned
by '=' operator", in your words. The result of 'x=3' expression is the
new value of 'x'.

Keep in mind though, that the compiler is not required to read that new
value specifically from 'x'. In order to generate the result (of 'x=3'
expression), the compiler can, for example, perform the actual
assignment and the read the new value of 'x'. Or the compiler can
"predict" the result by converting '3' to the type of 'x' without doing
the actual assignment first.

 

[jameskuyper]

(e-mail address removed) wrote: [...]

i don't think the operator can return a value.

Operators (or more accurately, expressions that contain an operator)
normally return a value, and assignment expressions are no exception
to that rule. Changing the value of 'x' is described by the C standard
as a side-effect - of course, that side-effect is usually the entire
reason for using an assignment expression, but it's still "just" a
side-effect as far as the standard is concerned.

A quibble about terminology:

Functions *return* values. Expressions *yield* values.

It's nearly the same thing, and it wouldn't be a tragedy if we used
the same word for both, but I find it helpful to keep the two concepts
distinct.

I thought about using 'yield', but decided in favor of 'return' in
order to match the terminology used in the message I was responding
to, to make it easier for exallion to see the connection between his
comment and my response. I was less than perfectly consistent in that
regard; I used "expression" rather than "operator", because I felt
that distinction was more important than the return/yield distinction.

 

[Ben Bacarisse]

Ben Bacarisse said:



Yes.

Hmm.. What do mean here?

It does, however, have a value, and this value can be assigned,
tested, passed, etc. The value of the expression x = -1 is -1 even
though it's not an lvalue (which isn't what was asked for).

The value is (unsigned int)-1, surely? To my mind this is not
negative and it is odd to say that it "is -1" even though it is a form
of -1.

 

[Keith Thompson]

Keith Thompson said:

(e-mail address removed) wrote: [...]
i don't think the operator can return a value.

Operators (or more accurately, expressions that contain an
operator) normally return a value, and assignment expressions are
no exception to that rule. Changing the value of 'x' is described
by the C standard as a side-effect - of course, that side-effect
is usually the entire reason for using an assignment expression,
but it's still "just" a side-effect as far as the standard is
concerned.

A quibble about terminology:

Functions *return* values. Expressions *yield* values.

In (at least) one place C89 uses the word 'return' to describe the
value yielded by any of several operators, and in another it uses
the word 'return' in connection with the assert macro. C99 also
uses the word in these ways.

It's nearly the same thing, and it wouldn't be a tragedy if we
used the same word for both, but I find it helpful to keep the two
concepts distinct.

I can understand that, although personally I use the word 'return'
freely with regard to operators, perhaps because I think of them,
in essence, as disguised functions.

Note that the editor of n1256.pdf (C99 with the three
Technical Corrigenda merged in) went through and changed the
wording to use "yield" consistently for the results of
expressions.

Ah, you see? You already knew!

Um, yes, I did.

But either they missed the use of
'return' in 7.2.1.1(3) or they're okay with the word 'return' being
associated with a macro.

You mean where it says "The assert macro returns no value."?

Yes, the whole description of the assert macro is a bit iffy. But the
point is that assert() is supposed to act like a function (except for
the part where the argument can be of any scalar type, and the text of
the argument is included in the message, and the argument isn't
evaluated if NDEBUG is defined, and so forth). So it's not entirely
unreasonable to talk about it returning or not returning a value.

 

[Martin Ambuhl]

Hello C Gurus,

Does the " = " operator return assigned value?
Following printf prints 3.
printf("X=%d",(x=3));
Does this print value of x or value returned by '"="
operator?

The value of x after evaluation of (x = 3) is 3.
The value of (x = 3) after evaluation is 3.
The value printed in printf(<specifier string>, <expression>);
is of <expression>, in this case of (x = 3); printf() does not have
access to anything that happens with <expression>. That means, in this
case, that none of the token in (x = 3) are visible to printf.

 

[Kenny McCormack]

Did the "Not quite." give it away? I was facing some indecision
between that and "Almost.", another CLC favorite.

Heh heh.

 

[Peter Nilsson]

Keith Thompson said:

...either they missed the use of 'return' in 7.2.1.1(3) or
they're okay with the word 'return' being associated with
a macro.

At most they're okay with the word being associated with
_that_ macro. It happens to be a function macro. Even though
such macros are not required to behave as functions, the
assert macro is certainly defined to behave like a void
function.

They also use return to describe what getc does even though
it has permission to be a macro that evaluates its argument
more than once.

 

[luserXtrog]

Hello C Gurus,

         Does the " = " operator return assigned value?
         Following printf prints 3.
         printf("X=%d",(x=3));
         Does this print value of x or value returned by '"="
operator?

Thanks
Sachin

You need to spy the tree through the leaves.
The compiler sees this line as something like this:

statement: function call
function name: printf
arg0: char * { 'X','=','%','d','\0' }
arg1: expression: parenthetic
sub-expression: assignment
lhs: variable x
rhs: integer 3

Your question appears to attempt to make a distinction which
makes no difference, unless the machinery of the grammar is
ignored. The heart of the compiler sees the '=' (the assignment
expression) before it sees x (lvalue identifier).
The assignment expression yields the value of the right-hand-side
as interpreted through the type of the left-hand-side.
Or you could say that it yields the value of the variable
after storing the new value. So it's both.

 

[Ben Bacarisse]

You need to spy the tree through the leaves.
The compiler sees this line as something like this:

statement: function call
function name: printf
arg0: char * { 'X','=','%','d','\0' }
arg1: expression: parenthetic
sub-expression: assignment
lhs: variable x
rhs: integer 3

Your question appears to attempt to make a distinction which
makes no difference, unless the machinery of the grammar is
ignored. The heart of the compiler sees the '=' (the assignment
expression) before it sees x (lvalue identifier).
The assignment expression yields the value of the right-hand-side
as interpreted through the type of the left-hand-side.

You /could/ say that but it would not be quite correct. What is the
type (and value) of

s.x = -1

in the context of this declaration:

struct { unsigned int x : 3; } s;

? The type alone does not explain the value.

Or you could say that it yields the value of the variable
after storing the new value.

This is what it is defined to be. OK, the "as if" rule allows the
compiler to avoid retrieving the value, but there is not doubt that
this is the correct explanation.

 

[James Kuyper]

Martin Ambuhl wrote:
[...]

The value of x after evaluation of (x = 3) is 3.
The value of (x = 3) after evaluation is 3.

What's the value of (x = 3) BEFORE evaluation?

It's the same as the value of x before definition.

 

[Guest]

Ben Bacarisse said:

seems pretty unambiguous to me!

Mean can't read. Missed the unsigned. Sorry. Just - um - just forget
I posted, okay?

and I was *just* reaching for my copy of the standard...

 

[Richard Bos]

Indeed

Aren't you clever.

Richard

 

[Kenny McCormack]

Aren't you clever.

Quite.