Velocity Reviews > Unexpected output

# Unexpected output

Paul N
Guest
Posts: n/a

 09-11-2011
On Sep 10, 9:42*pm, Eric Sosman <(E-Mail Removed)> wrote:
> * * *C has two distinct uses for the comma: as an operator, and as
> a separator. *The comma operator involves a defined order and a
> sequence point: `f = x,y' means "first evaluate x and ignore the
> value, sequence point, then evaluate y and yield its value, that
> value is assigned to f."

Just to be picky, won't that expression actually assign x to f, as the
= operator has a higher precedence than the , operator? (And yes, I
know the standard doesn't actually call it precedence.)

August Karlstrom
Guest
Posts: n/a

 09-11-2011
On 2011-09-10 21:36, Mazen wrote:
> Hello,
>
> Following is a simple program:
>
> #include<stdio.h>
>
> int main(void) {
> int i = 0, j, k;
> j = k = 2;
>
> printf("%d %d\n", i=+j, i=-j);
>
> return 0;
> }
>
> The output is
> 2 2
>
> Shouldn't the second expression be -2 rather than 2? I'm confused.

One obvious insight is that it's best to avoid side effects in
expressions if possible.

August

--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra

Eric Sosman
Guest
Posts: n/a

 09-11-2011
On 9/11/2011 3:08 PM, Paul N wrote:
> On Sep 10, 9:42 pm, Eric Sosman<(E-Mail Removed)> wrote:
>> C has two distinct uses for the comma: as an operator, and as
>> a separator. The comma operator involves a defined order and a
>> sequence point: `f = x,y' means "first evaluate x and ignore the
>> value, sequence point, then evaluate y and yield its value, that
>> value is assigned to f."

>
> Just to be picky, won't that expression actually assign x to f, as the
> = operator has a higher precedence than the , operator? (And yes, I
> know the standard doesn't actually call it precedence.)

Oops! Serves me right for editing my example ("for clarity," of
course) after writing it -- and after ceasing to think ...

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d

Ben Bacarisse
Guest
Posts: n/a

 09-11-2011
August Karlstrom <(E-Mail Removed)> writes:

> On 2011-09-10 21:36, Mazen wrote:
>> Hello,
>>
>> Following is a simple program:
>>
>> #include<stdio.h>
>>
>> int main(void) {
>> int i = 0, j, k;
>> j = k = 2;
>>
>> printf("%d %d\n", i=+j, i=-j);
>>
>> return 0;
>> }
>>
>> The output is
>> 2 2
>>
>> Shouldn't the second expression be -2 rather than 2? I'm confused.

>
> One obvious insight is that it's best to avoid side effects in
> expressions if possible.

The devil is in the detail. You presumably think that x = 1; is OK so
what about x++? How do you feel about *cp++ = 0? Maybe *dp++ = *s++?

At some stage most C programmers need to know what's permitted and what
is not. They may never need to know the rule itself, but they will
probably come up with the notion that, if an expression can yield two
different results with different (permitted) evaluation orders, then
there be dragons. This has the advantage of focusing on possible
evaluation orders which is an essential part of C programming.
printf("%d %d", f(), g()) may not be undefined, but the programmer would
be well advised to know that the order of execution is not specified.

--
Ben.

August Karlstrom
Guest
Posts: n/a

 09-12-2011
On 2011-09-11 23:51, Ben Bacarisse wrote:
> August Karlstrom<(E-Mail Removed)> writes:
>> One obvious insight is that it's best to avoid side effects in
>> expressions if possible.

>
> The devil is in the detail. You presumably think that x = 1; is OK so

Both `x = 1;' and `x++;' are atomic statements (they cannot be
decomposed into some other sequence of simpler statements), so yes they
are certainly OK.

> How do you feel about *cp++ = 0? Maybe *dp++ = *s++?

I feel that there is too much going on in each of these. Of course this
is to some degree a matter of preference but personally I don't think
these statements communicate very well and I think they are inherently ugly.

> At some stage most C programmers need to know what's permitted and what
> is not.

Yes, but if you write new code and adhere to the KISS principle you
don't need to bother with a lot of C's subtleties.

August

--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra

Ben Bacarisse
Guest
Posts: n/a

 09-12-2011
August Karlstrom <(E-Mail Removed)> writes:

> On 2011-09-11 23:51, Ben Bacarisse wrote:
>> August Karlstrom<(E-Mail Removed)> writes:
>>> One obvious insight is that it's best to avoid side effects in
>>> expressions if possible.

>>
>> The devil is in the detail. You presumably think that x = 1; is OK so

>
> Both `x = 1;' and `x++;' are atomic statements (they cannot be
> decomposed into some other sequence of simpler statements), so yes
> they are certainly OK.
>
>> How do you feel about *cp++ = 0? Maybe *dp++ = *s++?

>
> I feel that there is too much going on in each of these. Of course
> this is to some degree a matter of preference but personally I don't
> think these statements communicate very well and I think they are
> inherently ugly.

That's a logical place to draw the line, but I can't go along with it.
I can't say why except that is seems un-C-like to reject them. There's
no logic to my point of view -- it seems to be no more that a matter to
taste than anything else.

<snip>
--
Ben.

Seebs
Guest
Posts: n/a

 09-13-2011
On 2011-09-10, arni <(E-Mail Removed)> wrote:
> On Sep 10, 11:49?pm, Eric Sosman <(E-Mail Removed)> wrote:
>> On 9/10/2011 4:31 PM, arni wrote:
>> > Shouldn't it be i+=j and i-=j?.. Then you'll get 2 -2.

>> ? ? ?Or not: The behavior would still be undefined, and for the
>> same reason as before.

> Depends on compiler/optimizer implementation.

Whether or not it is undefined does not depend on that. What you get does.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Phil Carmody
Guest
Posts: n/a

 09-13-2011
Keith Thompson <(E-Mail Removed)> writes:
> Mazen <(E-Mail Removed)> writes:
> [...]
> > I have learned the attempting to assign a value to a variable and
> > fetching the value of it in the same expression will produce an
> > undefined behaviour.

>
> As Joe Pfeiffer points out, that's not quite correct.
>
> > What are some of the other cases that produce
> > undefined behaviour? This is interesting!

>
> Grab a copy of the latest C99 draft from
>
> http://www.open-std.org/jtc1/sc22/wg...docs/n1256.pdf
>

This might be a better introduction, to lead up to the formality
of the official docs:
http://c-faq.com/expr/index.html

Phil
--
"Religion is what keeps the poor from murdering the rich."
-- Napoleon

August Karlstrom
Guest
Posts: n/a

 09-13-2011
On 2011-09-12 20:55, Ben Bacarisse wrote:
> August Karlstrom<(E-Mail Removed)> writes:
>> On 2011-09-11 23:51, Ben Bacarisse wrote:
>>> How do you feel about *cp++ = 0? Maybe *dp++ = *s++?

>>
>> I feel that there is too much going on in each of these. Of course
>> this is to some degree a matter of preference but personally I don't
>> think these statements communicate very well and I think they are
>> inherently ugly.

>
> That's a logical place to draw the line, but I can't go along with it.
> I can't say why except that is seems un-C-like to reject them. There's
> no logic to my point of view -- it seems to be no more that a matter to
> taste than anything else.

The question is, when does a statement become too complex? Programming
structured programming, user defined functions and so on was invented. I
myself prefer to focus my energy on algorithms rather than on
intricacies of the programming language.

Also, a complex expression with multiple side effects in a statement
does not make the algorithm any simpler - only shorter, but not simpler.
statement aloud or write it in plain English it is not shorter. It just
makes for a longer and more convoluted sentence.

So, although writing convoluted code is a part of the C tradition, if
you can resist the temptation of saving a few keystrokes you will
probably save some maintenance time in the future. As we all know, C
does not enforce or advocate any particular coding style. On the
contrary, giving the programmer maximum freedom, and that includes the
freedom to write clear code, is the spirit of C.

August

--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra