Pre And Post Increment Operator Output

[Guest]

no.

no. Once I realised the program contained unnecessary undefined behaviour, I'd remove it. No guesses necessary.

OK, so we fix it so that the result is ....? Any guesses?

"a suffusion of yellow"

Changing the erroneous code so that it stays within the rules:

int i = 0;
int t1,t2,t3;

t1=++i;
t2=++i;
t3=++i;
i=t1+t2+t3;
printf("%d",i);

Now gives a valid result. Which happens to coincide with the OP's
expectations, and with what I said it *ought* to be (for which I was called
a 'nitwit', even though I went on to explain why the OP wasn't getting that
result),

a bit harsh but you plainly don't understand what "undefined behavior" means.

and in fact with what most of my compilers were already giving me
anyway; presumably they were already using code along the same lines!)

a more mysterious one was posted recently. It was only by looking at the assembler was anyone able to explain the result.

However, the interesting question is, why anyone - outside c.l.c obviously -
might think the output of the OP's original code might be 6, rather than any
other number (or any other manifestation, according to previous threads
along the same lines).

i = (i + 3) + (i + 3) + (i + 3)
i = i + 3

Or, are we not allowed to think or guess anything at all, simply because the
C standard says the original expression has undefined behaviour?

no. If the implementor decides to tell you what the behaviour is- and guarantees the behaviour then you might trust that. Some UB is commonly
used,
unsigned *reg = (unsigned*)0x8010;
*reg = 0x01; // fire lasers

but I can see no point in silly code like this threads

 

[Eric Sosman]

Intentionally or not, a large number of BartC's posts are troll-ish.
For this reason, I send his messages to the bit bucket.

For someone whose understanding of C is shaky at best (see recent
threads concerning unsigned arithmetic), BartC spouts off an awful lot
of rash opinions. I read his drivel mostly because some of it needs
contradicting lest it mislead readers: "All that is necessary for the
triumph of evil is that good men do nothing." I don't know whether
BartC is actually evil or just a blunderer, but "nitwit" seems fitting
either way.

 

[Ben Bacarisse]

OK, so we fix it so that the result is ....? Any guesses?

Argh! Another chasm opens up! There can be no guess. You fix it by
choosing what you want it to mean. You choose it to mean 6, so you "fix
it" (in all senses of the word) by re-writing it as:

Changing the erroneous code so that it stays within the rules:

int i = 0;
int t1,t2,t3;

t1=++i;
t2=++i;
t3=++i;
i=t1+t2+t3;
printf("%d",i);

Now gives a valid result. Which happens to coincide with the OP's
expectations,

It doesn't just "happen" to coincide -- you forced it to. You have a
view of what the code "really" means, but that's just one rather
arbitrary point of view. To take another, ++i, when i is zero, sets i
to 1 and has the value one. The statement

i = ++i + ++i + ++i;

could, in this context, be taken to mean

i = (i = 1) + (i = 1) + (i = 1);

which is still undefined of course but it looks quite different and your
expectation would probably be different.

The purpose of the sequence point rule (now gone) was to allow the
compiler to say "I know what value ++i has here, and I don't need to
change my mind about that until the next sequence point".

I've never liked the view that anything can happen with undefined code;
it sounds too much like a cheap pedagogical trick to say that the above
could format your drive. But the other extreme -- we all know what
*should* happen, don't we? -- is equally unconvincing. When the C
language does not define the meaning of a bit of code, something else
does, and that's enough for me. I don't want to write code whose
meaning is in the hands of unknown entities. This point of view covers
the much more significant case where I *know* what entity will define
the meaning of otherwise undefined code -- POSIX, for example.

and with what I said it *ought* to be (for which I was
called a 'nitwit', even though I went on to explain why the OP wasn't
getting that result), and in fact with what most of my compilers were
already giving me anyway; presumably they were already using code
along the same lines!)

However, the interesting question is, why anyone - outside c.l.c
obviously -
might think the output of the OP's original code might be 6, rather
than any other number (or any other manifestation, according to
previous threads along the same lines).

Or, are we not allowed to think or guess anything at all, simply
because the C standard says the original expression has undefined
behaviour?

Think and guess all you like, but it's disingenuous to suggest that's
all you were doing. You said the value *ought* to be 6 and that's got
to be designed to get a more robust response, no?

 

[John Bode]

I am new to see and wanna learn it deeply

Could u guyz tell me some good books or web links

For *learning* C:

- "The C Programming Language", Kernighan & Ritchie, 2nd ed.
While a bit out of date (doesn't cover anything after the
C89 standard), it's still one of the best general introductions
to the language.

- "C Programming: A Modern Approach", K.N. King, 2nd ed. While
I don't have any direct experience with this book, people I
trust recommend it highly.

For *working* in C:

- "C: A Reference Manual", Harbison & Steele, 5th ed. My go-to
reference starting with the 2nd edition in the 1980s. Not the
greatest *learning* resource, but invaluable to have at your
side when you're trying to remember how something works.

The Language Standard:

- A publicly available draft of the 2011 standard is available
at the link below:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf

This isn't the final, official version, but it's close enough
most practical purposes. Again, not a great *learning* resource,
but invaluable to have handy.

 

[Les Cargill]

Ben Bacarisse wrote:

Think and guess all you like, but it's disingenuous to suggest that's
all you were doing. You said the value *ought* to be 6 and that's got
to be designed to get a more robust response, no?

Oy, "is-ought distinction" in c.l.c! To the tune of "anarchy in the UK"...

 

[lawrence.jones]

- A publicly available draft of the 2011 standard is available
at the link below:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf

This isn't the final, official version, but it's close enough
most practical purposes. Again, not a great *learning* resource,
but invaluable to have handy.

Even closer is N1570, which is identical to the official version except
for the headers/footers and the addition of diff marks indicating
changes from N1539.

 

[Keith Thompson]

OK, so we fix it so that the result is ....? Any guesses?

No, I don't care to guess, any more than I'd care to guess what value:

srand(0);
printf("%d\n", rand());

"should" print (and that's merely an unspecified result, not undefined
behavior). To know what what it's *supposed* to print, I'd have to ask
the author of the code and find out what he had in mind. My knowledge
of the C language provides no guidance.

Changing the erroneous code so that it stays within the rules:

int i = 0;
int t1,t2,t3;

t1=++i;
t2=++i;
t3=++i;
i=t1+t2+t3;
printf("%d",i);

Now gives a valid result. Which happens to coincide with the OP's
expectations, and with what I said it *ought* to be (for which I was called
a 'nitwit', even though I went on to explain why the OP wasn't getting that
result), and in fact with what most of my compilers were already giving me
anyway; presumably they were already using code along the same lines!)

Yes, that's one of many possible transformations of the original code
that eliminates the undefined behavior. Other such transformations will
produce different results. Here's mine, which produces the same output
as the original code with gcc:

putchar('7');

However, the interesting question is, why anyone - outside c.l.c obviously -
might think the output of the OP's original code might be 6, rather than any
other number (or any other manifestation, according to previous threads
along the same lines).

Or, are we not allowed to think or guess anything at all, simply because the
C standard says the original expression has undefined behaviour?

If someone assumed that the output should be 6, it would probably
because he assumed strict left-to-right evaluation. I would see this as
an opportunity to educate the person with this misconception, and teach
him that the C language does not guarantee, or even imply, any such
evaluation order.

In a professional setting, it doesn't matter what result the original
code produces; it will never survive code review.

 

[Keith Thompson]

The Language Standard:

- A publicly available draft of the 2011 standard is available
at the link below:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf

This isn't the final, official version, but it's close enough
most practical purposes. Again, not a great *learning* resource,
but invaluable to have handy.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf is more
current, and the actual 2011 ANSI C standard is available for $30 from
ANSI at:

http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS/ISO/IEC+9899-2012

<OT>The 2011 C++ standard is also available.</OT>

 

[Eric Sosman]

[...]
In a professional setting, it doesn't matter what result the original
code produces; it will never survive code review.

Once upon a time, a bug drew my attention to code like

output = f(input[i++]); /* Tricksy */

The executable portion is paraphrased, but the comment is seared
into my memory and is given verbatim. Had it not been there I'd
simply have thought "Ah: Poor schnook doesn't know C very well."
But its presence suggested something rather different, and rather
more culpable: The perpetrator *knew* he was in the wrong, yet
chose to go ahead anyhow -- presumably, because on one of our
eight or nine platforms at whatever optimization level he tried,
the generated code happened to do what he wanted. Oh, yummy.

Thoughts of pickaxes came to me, but I suppressed the urge to
give the offender the treatment he richly deserved. Besides, he
outranked me: He was a Fellow of our engineering department, which
may explain why he got kid-glove treatment in code reviews ...

 

[Tim Rentsch]

Nitwit.

Did you not read the rest of his comments? He explained further
on that C allows other possibilities, and this comment is only
expressing an opinion.

 

[Phil Carmody]

Yet, given the OP's program, and a randomly assigned but unknown compiler,
what result would you put your money on, if you were obliged to gamble?

I would not waste my time with such idiotic games. One easy way to
make that easier is to not waste time with idiotic people.

Phil
--

I'd argue that there is much evidence for the existence of a God.

Pics or it didn't happen.
-- Tom (/. uid 822)

 

[Phil Carmody]

Did you not read the rest of his comments? He explained further
on that C allows other possibilities, and this comment is only
expressing an opinion.

His opinion is that C should be not-C.

Phil
--

I'd argue that there is much evidence for the existence of a God.

Pics or it didn't happen.
-- Tom (/. uid 822)

 

[Tim Rentsch]

His opinion is that C should be not-C.

Maybe, but not necessarily. It could just as easily be an opinion
about implementations rather than the C language itself. There is
nothing incompatible with the behavior suggested and what the C
language requires.

However, even if it is an opinion about the C language, so what?
There are plenty of things about C that I think exhibit varying
degrees of wrongheadedness in terms of language design. In fact
I don't know anyone who thinks everything about C is right and
nothing about it should be changed. Expressing an opinion about
C's perceived shortcomings doesn't per se make one a nitwit. As
it happens I personally disagree with this opinion about the C
language (assuming it is an opinion about the language and not
about implementations, which is a whole other story), but I don't
think it's so outrageous a viewpoint that anyone holding it must
be hopelessly addled.

 

[Guest]

"BartC" <[email protected]> writes:

I've never liked the view that anything can happen with undefined code;
it sounds too much like a cheap pedagogical trick to say that the above
could format your drive.

a poster on here used to claim he'd seen a system pop up the old DOS dialog box saying "Are You Sure You Want To Reformat C:?". For some sort of UB (not tricks with ++ but (I think) some sort of out of bounds thing).

But the other extreme -- we all know what
*should* happen, don't we? -- is equally unconvincing. When the C
language does not define the meaning of a bit of code, something else
does, and that's enough for me. I don't want to write code whose
meaning is in the hands of unknown entities. This point of view covers
the much more significant case where I *know* what entity will define
the meaning of otherwise undefined code -- POSIX, for example.

I've seen program behaviour change due to UB when a compiler was upgraded (same manufacturer). Changing optimisation can do it too.

<snip>

 

[BartC]

Maybe, but not necessarily. It could just as easily be an opinion
about implementations rather than the C language itself. There is
nothing incompatible with the behavior suggested and what the C
language requires.

However, even if it is an opinion about the C language, so what?

There are plenty of things about C that I think exhibit varying
degrees of wrongheadedness in terms of language design. In fact
I don't know anyone who thinks everything about C is right and
nothing about it should be changed.

(I'm interested in language design and many of the threads I participated in
were on those subjects. They necessarily have to involve ideas from outside
C. Although this wasn't meant to be one of them; nothing was proposed.)

Expressing an opinion about
C's perceived shortcomings doesn't per se make one a nitwit. As
it happens I personally disagree with this opinion about the C
language (assuming it is an opinion about the language and not
about implementations, which is a whole other story), but I don't
think it's so outrageous a viewpoint that anyone holding it must
be hopelessly addled.

(I discuss my comment some more in comp.programming, under the same subject
line. But the bottom line is that that throwaway remark wasn't about C at
all.)

I don't know whether BartC is actually evil

(It's nice to know some people in this group have more open minds than Mr
ES!)

 

[Ben Bacarisse]

a poster on here used to claim he'd seen a system pop up the old DOS
dialog box saying "Are You Sure You Want To Reformat C:?". For some
sort of UB (not tricks with ++ but (I think) some sort of out of
bounds thing).

Exactly. Even beginners soon realise that "anything can happen" is not
really true. The truth should be scary enough.

I've seen program behaviour change due to UB when a compiler was
upgraded (same manufacturer). Changing optimisation can do it too.

Yup, or even just using different compiler options. You want to be the
one defining what your programs mean, not leaving up to other entities
(unless you need to like in my POSIX example).

 

[Eric Sosman]

[...]
I've seen program behaviour change due to UB when a compiler was upgraded (same manufacturer). Changing optimisation can do it too.

Even an "unrelated" change to the program can expose UB in
an unchanged section. See also "Heisenbug."

 

[Tim Rentsch]

(I'm interested in language design and many of the threads I participated in
were on those subjects. They necessarily have to involve ideas from outside
C. Although this wasn't meant to be one of them; nothing was proposed.)


(I discuss my comment some more in comp.programming, under the same subject
line. But the bottom line is that that throwaway remark wasn't about C at
all.)

May I courteously suggest that it would have been better if that
had been made clear in your comment. Perhaps something along
the lines of "In a more sensibly designed language, this would ...".
That is better all around, I think, ie, both for the OP and for
other folks (I would count myself as one of these) who are more
entrenched in C as defined by the Standard.

in message

(It's nice to know some people in this group have more open minds than
Mr ES!)

In most cases I try to read postings based on what they say and
not on who is doing the saying. Also I am willing to listen to
other points of view, reasonably expressed, even if I don't
necessarily agree with them. Now if the reasoning backing up
a point of view is gibberish, then I am perfectly willing to
call it gibberish, but that's about the reasoning, not about
just having a different view. Some people don't make that
distinction.

 

[Bartc]

For someone whose understanding of C is shaky at best (see recent
threads concerning unsigned arithmetic), BartC spouts off an awful lot
of rash opinions.

I've just read through the thread again, or what's left of it on my server.
(I assume you mean the "condition true or false..." thread.)

You're right, I didn't know stuff about 'closed operations', 'finite groups'
and 'additive inverses', or whether a denotation such as 82537 is called a
constant or a literal. But you shouldn't need do.

For those who haven't read it, the OP there was wondering why C was saying
that '-1 < 5' (when expressed in a certain way) was False. My 'rash
opinion' was suggesting that that was wrong!

Of course no-one is allowed to have opinion on that, unless they're a
complete expert on the language and know the Standard inside out!
Explanations why things are as they are are all very well, but people,
including non-conformist outsiders like me, should be allowed to question
them.

I read his drivel mostly because some of it needs
contradicting lest it mislead readers:

Most of my points still stand. I think they were perfectly reasonable in the
context of a proposed 'fantasy' change to the language. I don't think anyone
was misled in that thread.

(I sometimes like to side with OPs. If their post brings up something
questionable in the language, then I find that interesting. If they expect
things to work a certain way, then perhaps that's the way they should work!

When I was designing user interfaces, then I used the same reasoning. It was
just easier than complicated explanations and a thicker user manual.

Although C itself is a closed book here, I'm designing two languages of my
own. I have to decide, from time to time, whether to adopt an existing
practice, eg. from C, or find another way. In the case of C's mixed
arithmetic handling, I once asked for a 'rationale' for it, and that thread
gave me most of it. (A belated thanks...). However I decided to do my own
thing there**.)

(** On one language, unsigned types are partly eliminated, which is one way
to deal with the problem. On the other more C-like language, mixed
arithmetic was going to use signed, as presenting fewer surprises. But I
think I will insist on explicit casting instead; then any surprises won't be
as unexpected.

In the case of i=0; i=++i+ ++i+ ++i, I don't guarantee the result of that
either. But that has nothing to do with the common-sense expectation of what
such an expression might do. Ie. end up with i==6! Sadly everyone missed the
point. I know I'm risking a third 'nitwit' remark from Eric, or something
equally belittling, but I'm no longer bothered.)

 

[Ben Bacarisse]

I've just read through the thread again, or what's left of it on my server.
(I assume you mean the "condition true or false..." thread.)

You're right, I didn't know stuff about 'closed operations', 'finite groups'
and 'additive inverses', or whether a denotation such as 82537 is called a
constant or a literal. But you shouldn't need do.

No you shouldn't, and of course you don't, but suggesting that you do
is a good way to stir up this month-old controversy again.

What you need to know, though, is the language's rules and it's that
rather mundane fact that you lament. You don't like the fact that C is
not obvious, that some results are unexpected, that you have to know
quite a lot of details to avoid surprises.

For those who haven't read it, the OP there was wondering why C was saying
that '-1 < 5' (when expressed in a certain way) was False. My 'rash
opinion' was suggesting that that was wrong!

For those who haven't read it, Bartc is characterising the question so
as to make it look absurd. -1 < 5 is always 1 in C, and no relational
expression is ever "False" (I'm not sure what the significance of the
capital F is but it looks significant).

Here, again, C shows its readiness to confound those who don't know the
rules. C's relational operators produce an int result (either 0 or 1)
and never produce a Boolean result, despite the fact that C has a Boolean
type called _Bool (yes, they didn't make even the type name obvious).

I am not sure, but I suspect that Eric's remark about "rash opinions" is
more likely to be about your suggestions for how C's mixed type
arithmetic should be done. I think it *is* rash to suggest how a
programming language should behave unless you know it very well indeed.

Of course no-one is allowed to have opinion on that, unless they're a
complete expert on the language and know the Standard inside out!
Explanations why things are as they are are all very well, but people,
including non-conformist outsiders like me, should be allowed to question
them.

Are you confusing being allowed with being agreed with? No one stopped
you from questioning things as they are as far as I can tell.

... I'm designing two languages of my own.

In the case of i=0; i=++i+ ++i+ ++i, I don't guarantee the result of that
either. But that has nothing to do with the common-sense expectation of what
such an expression might do. Ie. end up with i==6! Sadly everyone missed the
point.

No, I don't think everyone did miss your point.

Just in case, here's mine again: the notion of common sense is not
applicable to programming languages, as this very thread shows. For
people who don't program but who have common sense in abundance, the
only response to seeing

i=0; i=++i+ ++i+ ++i;

should be to ask what that notation means. People who know one or two
languages in which that sequence of tokens has a well-defined meaning
would be most rash to assume it has the same meaning in another
language. To make such an assumption is not common sense -- it's the
opposite of common sense. Such people (coming from a C# and Java
background for example) may well have a deceptive expectation, but their
common sense should save them from it.

Try it yourself. What does this do:

f = (+1);

and is any language which does not match what your expectation flawed as
a result?

<snip>