Doubt in Question From C Faq

[Skarmander]

http://www.faqs.org/faqs/C-faq/abridged/
3.1: Why doesn't the code "a = i++;" work?

A: The variable i is both referenced and modified in the same
expression.

Here is the code that I have written:
#include <stdio.h>

int main ()
{
int a[] = {1,2,3,4,5,6};
int i=1;
int j;

a = i++;
for(j=0;j<6;j++)
printf("%d\n",a[j]);
}

Outout (using gcc (GCC) 3.4.2 (mingw-special))

1
1
3
4
5
6

It works fine for me !

WHAT??? Take another look at your results...
HINT: where is the number 2???

I ate it.

Reread the program, then look for a brown paper bag to pull over your
head. HINT: what does assignment do?

Exactly.
Is assignment, a sequence point?
No!
Is an expression defined when it modifies
and accesses an object without an intervening sequence point?
No!
Is a = i++; C code?
No,
it's just gibberish that looks like C code.

Yes, I know. I did read the rest of the thread.

The comment "where is the number 2" still makes no sense. If you did
*not* expect this to be undefined behavior (as the OP did) then the
result he got indeed "work fine for him". That is, a = i++ sets a[1]
to 1 and there is no surprise.

I might as well have posted:

WHAT??? Take another look at your results...
HINT: where are the demons that are supposed to fly out of your nose???

S.

 

[Mark McIntyre]

http://www.faqs.org/faqs/C-faq/abridged/
3.1: Why doesn't the code "a = i++;" work?

A: The variable i is both referenced and modified in the same
expression.

snip Example of the above.

It works fine for me ! Maybe I have not understood the question "Why
doesn't the code "a = i++;" work?"

It doesn't work reliably because its not required to work reliably.

. Any ideas ?

Its undefined behaviour. "Undefined" includes "working perfectly in
debug mode on Tuesdays". It also includes "failing horribly in front
of your boss and prospective clients".

It doesn't matter whether your specific compiler and specific
installation do this "properly", Its not guaranteed to work and you
absolutely should not do it.

 

[Mark McIntyre]

pemo said:
a = i++;
Isn't it the
case that post-increment is always the last thing done - whereas
pre-increment is alwats the first thing done? In that case, surely the
valie of i is consistently the same on both sides of the assignment
operator?

This is what confused me.

a = ++i; // Logical to say that "i" has changed before the
expression could end
a = i++; // This seemed ok to me.

There are multiple possible orders of evaluation. The C Standard
doesn't impose any specific one. Therefore you, the user, cannot
guarantee how it will behave.

But do you think there is a reason for having this undefined
behaviour?

Iits undefined because there are multiple possible evaluation orders,
all of which 'make sense', and there is no way to say "this one is
right, and this one is wrong".

Is the reason to be consistent with the pre-increment
operator ?

No.

 

[Mark McIntyre]

oops sorry, 2,2,3,4,5,6 is impossible but 1,2,3,4,5,6 is still a
possible result.

No, thats possible too. So are any of

2,2,2,2,2,2
1,1,2,3,4,-NAN, access violation, core dumped
and of course
"+++++REDO FROM START"

That dratted dwarf gets everywhere.

 

[pete]

Mark B wrote:



http://www.faqs.org/faqs/C-faq/abridged/
3.1: Why doesn't the code "a = i++;" work?

A: The variable i is both referenced and modified in the same
expression.

Here is the code that I have written:
#include <stdio.h>

int main ()
{
int a[] = {1,2,3,4,5,6};
int i=1;
int j;

a = i++;
for(j=0;j<6;j++)
printf("%d\n",a[j]);
}

Outout (using gcc (GCC) 3.4.2 (mingw-special))

1
1
3
4
5
6
HINT: where is the number 2???

The comment "where is the number 2" still makes no sense.

OK

One thing to remember here,
is that assignment is not a sequence point.
For:

int a;
float b;
char c;

This statement
a = b = c;
could be rendered as:
a = (int)(float)c,
b = c;

It makes a big difference in something like this:
sorted -> next = *node;
sorted = *node;
which is undefined if written as:
sorted = sorted -> next = *node;



list_type *list_merge(list_type *head, list_type *tail,
int (*compar)(const list_type *, const list_type *))
{
list_type *list, *sorted, **node;

node = compar(head, tail) > 0 ? &tail : &head;
sorted = list = *node;
*node = sorted -> next;
while (*node != NULL) {
node = compar(head, tail) > 0 ? &tail : &head;
sorted -> next = *node;
sorted = *node;
*node = sorted -> next;
}
sorted -> next = head != NULL ? head : tail;
return list;
}

 

[Keith Thompson]

pemo said:
a = i++;

[...]
But do you think there is a reason for having this undefined
behaviour?

Iits undefined because there are multiple possible evaluation orders,
all of which 'make sense', and there is no way to say "this one is
right, and this one is wrong".

That's only part of the picture. The fact that there are multiple
possible evaluation orders does not by itself make the behavior
undefined. For example, consider this program:

#include <stdio.h>
#include <string.h>

static char message[50] = "";

int f(void)
{
strcat(message, "F");
return 2;
}

int g(void)
{
strcat(message, "G");
return 3;
}

int main(void)
{
printf("f() returns %d, g() returns %d\n", f(), g());
printf("message = \"%s\"\n", message);
return 0;
}

The first printf() must print
f() returns 2, g() returns 3
but the second can print either
message = "FG"
or
message = "GF"
depending on the order of evaluation of the arguments to printf().
But the program must produce one of the two results. There's no
undefined behavior because no object is modified twice between
sequence points. (The printf() call doesn't create a sequence point
between f() and g(), but the calls to f() and g() themselves create
sequence point.)

The existence of multiple evaluation orders is a large part of the
rationale for making a=i++ undefined, but the bottom line is that
it's undefined because the standard says so.

 

[Mark McIntyre]

That's only part of the picture. The fact that there are multiple
possible evaluation orders does not by itself make the behavior
undefined.

Absolutely. It makes it at best unspecified. I was simlpifying