Most compilers can't do a simple sum 
Author Message
 Most compilers can't do a simple sum

I dreamed up a little sample C program today that seems
to defeat practically every C compiler known to man.

Here's the program:

#include<stdio.h>
void main()
{
  int x = 0, a = 0;
  x = (++a) + (++a) + (++a);
  printf("x = %d\n", x);

Quote:
}

I believe the correct output should be:

x = 6

However...
I and a couple of other folk have tried this out on various
compilers and the results are:

Visual C++ 6:      x = 7
Visual C++.NET:    x = 9
C++ Builder 4      x = 9
GNU C compiler:    x = 7
awk script (UNIX): x = 7
acc (Solaris UNIX):x = 9
IBM AIX compiler:  x = 7
cc on HPUX:        x = 6

We can see that most of the
popular and most-commonly-used C compilers around at the
moment are incapable of doing a simple sum.

Are the authors of these compilers aware of this problem?
Seems a bit worrying when C/C++ is so widely used in mission-critical
applications.



Sat, 25 Sep 2004 23:19:34 GMT  
 Most compilers can't do a simple sum


Quote:
> I dreamed up a little sample C program today that seems
> to defeat practically every C compiler known to man.

> Here's the program:

> #include<stdio.h>
> void main()
> {
>   int x = 0, a = 0;
>   x = (++a) + (++a) + (++a);

Hmm, does the '+' provide a sequence point? If not, you've entered into
undefined behavior.


Sat, 25 Sep 2004 23:23:05 GMT  
 Most compilers can't do a simple sum




Quote:
> > I dreamed up a little sample C program today that seems
> > to defeat practically every C compiler known to man.

> > Here's the program:

> > #include<stdio.h>
> > void main()

int main(void)

Quote:
> > {
> >   int x = 0, a = 0;
> >   x = (++a) + (++a) + (++a);

reading the assembly code generated may be instructive.

Quote:
> Hmm, does the '+' provide a sequence point? If not, you've entered into
> undefined behavior.

it does not provide a sequence point, hence the variable output described by
the OP.

a version provided by my lecturer to demonstrate the dangers of undefined
behaviour is the following:

/*invokes undefined behaviour*/

#include <stdio.h>

int x = 1;
int y = 1;

int g(void)
{
    return ++y;

Quote:
}

int main(void)
{
    x = ++x + ++x;
    y = g() + g();

    printf("x: %d; y: %d\n", x, y);

    return 0;

Quote:
}

/*end of program---------------------------*/

figure the results out for yourself...



Sat, 25 Sep 2004 23:46:24 GMT  
 Most compilers can't do a simple sum


Quote:
> I dreamed up a little sample C program today that seems
> to defeat practically every C compiler known to man.

> Here's the program:

> #include<stdio.h>
> void main()

This line alone causes the program to have undefined
behavior.  'main()' is *required* to return type 'int'

int main()

Quote:
> {
>   int x = 0, a = 0;
>   x = (++a) + (++a) + (++a);
>   printf("x = %d\n", x);

    return 0;  /* main() is required to return type 'int' */
               /*   (this line is optional for C99, required */
               /*    for C90)

Quote:
> }

> I believe the correct output should be:

> x = 6

It could be anything.  Your code produces undefined
behavior.  Look up 'sequence points'.

Quote:
> However...
> I and a couple of other folk have tried this out on various
> compilers and the results are:

> Visual C++ 6:      x = 7
> Visual C++.NET:    x = 9
> C++ Builder 4      x = 9
> GNU C compiler:    x = 7
> awk script (UNIX): x = 7
> acc (Solaris UNIX):x = 9
> IBM AIX compiler:  x = 7
> cc on HPUX:        x = 6

> We can see that most of the
> popular and most-commonly-used C compilers around at the
> moment are incapable of doing a simple sum.

Not true.  They won't produce consistent results for
invalid code.

Quote:

> Are the authors of these compilers aware of this problem?

Yes, I think compiler authors know what constructs must
produce defined behavior, and which are not required to.

Quote:
> Seems a bit worrying when C/C++ is so widely used in mission-critical
> applications.

More worrying that so many people use it incorrectly. :-)

-Mike



Sun, 26 Sep 2004 00:08:40 GMT  
 Most compilers can't do a simple sum

Quote:

> I dreamed up a little sample C program today that seems
> to defeat practically every C compiler known to man.

> Here's the program:

> #include<stdio.h>
> void main()
> {
>   int x = 0, a = 0;
>   x = (++a) + (++a) + (++a);
>   printf("x = %d\n", x);
> }

> I believe the correct output should be:

> x = 6

You do?

I think the correct output would come out your nose.
As demons that is.

As this is UB we are both right and wrong :)

See the faq (www.google.com type in 'comp.lang.c faq' and press
the I'm feeling lucky button)

--
Thomas.



Sat, 25 Sep 2004 23:51:25 GMT  
 Most compilers can't do a simple sum

Quote:
> I dreamed up a little sample C program today that seems
> to defeat practically every C compiler known to man.
> Here's the program:
> #include<stdio.h>
> void main()
> {
>   int x = 0, a = 0;
>   x = (++a) + (++a) + (++a);
>   printf("x = %d\n", x);
> }

(snip)

Quote:
> Are the authors of these compilers aware of this problem?
> Seems a bit worrying when C/C++ is so widely used in mission-critical
> applications.

Please read the FAQ. When you have done it, you will realise that the
message you just posted is equivalent to:

"I just got a fresh stack of $100 bills from the bank and burned them
all to cinder. Why can't the government print proper money instead of
this toy stuff? What kind of joke for a society are we living in
anyway?"

--

| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste       W++ B OP+                     |
\----------------------------------------- Finland rules! ------------/
"Nothing lasts forever - so why not destroy it now?"
   - Quake



Sun, 26 Sep 2004 00:01:59 GMT  
 Most compilers can't do a simple sum

Quote:






[snip]

Quote:

>>Hmm, does the '+' provide a sequence point? If not, you've entered into
>>undefined behavior.

> it does not provide a sequence point, hence the variable output described by
> the OP.

I think he knew that...

Quote:

> a version provided by my lecturer to demonstrate the dangers of undefined
> behaviour is the following:

> /*invokes undefined behaviour*/

> #include <stdio.h>

> int x = 1;
> int y = 1;

> int g(void)
> {
>     return ++y;
> }

> int main(void)
> {
>     x = ++x + ++x;
>     y = g() + g();

Hmm, is this really UB? Since a statement always has at least one
sequence point. There is a sequence point after each modification
AFAIK...

[snip]

--
Thomas



Sun, 26 Sep 2004 01:32:20 GMT  
 Most compilers can't do a simple sum

Quote:

>> a version provided by my lecturer to demonstrate the dangers of undefined
>> behaviour is the following:

>> /*invokes undefined behaviour*/

>> #include <stdio.h>

>> int x = 1;
>> int y = 1;

>> int g(void)
>> {
>>     return ++y;
>> }

>> int main(void)
>> {
>>     x = ++x + ++x;
>>     y = g() + g();
> Hmm, is this really UB? Since a statement always has at least one
> sequence point. There is a sequence point after each modification
> AFAIK...

y = g() + g(); does NOT invoke undefined behaviour. A function call
constitutes a sequence point. So what happens is:

1. Evaluation of "y = g() + g()" begins
   1.1. "y" can be evaluated here, but it doesn't have to be
   1.2. Evaluation of "g() + g()" begins
        1.2.1. Evaluation of one "g()" begins
               1.2.1.1. y is incremented by one and its value is
                        returned
               1.2.1.2. ***SEQUENCE POINT***
        1.2.2. Evaluation of one "g()" ends
        1.2.3. Evaluation of the other "g()" begins
               1.2.3.1. y is incremented by one and its value is
                        returned
               1.2.3.2. ***SEQUENCE POINT***
        1.2.4. Evaluation of the other "g()" ends
        1.2.5. The values of "g()" and "g()" are summed together
   1.3. Evaluation of "g() + g()" ends
   1.4. If "y" was not evaluated at 1.1, then it's evaluated here
   1.5. The result of "g() + g()" is assigned to y
2. Evaluation of "y = g() + g()" ends
3. ***SEQUENCE POINT***

Notice, that by the time we have evaluated what we are assigning to
y, we have already passed two sequence points, so it's clear that
the evaluation of "g() + g()" must happen before the assignment.

If g() was implemented as a macro:
#define g() (++y)

THEN we would have undefined behaviour. Macro expansion does not
constitute a sequence point unless there is a sequence point inside
what the macro expands to, and there is no sequence point in (++y).

--

| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste       W++ B OP+                     |
\----------------------------------------- Finland rules! ------------/
"Bad things only happen to scoundrels."
   - Moominmamma



Sun, 26 Sep 2004 01:52:06 GMT  
 Most compilers can't do a simple sum
Quote:




[snip]

Quote:
>>>int y = 1;

[snip]

Quote:
> y = g() + g(); does NOT invoke undefined behaviour. A function call
> constitutes a sequence point. So what happens is:

> 1. Evaluation of "y = g() + g()" begins
>    1.1. "y" can be evaluated here, but it doesn't have to be
>    1.2. Evaluation of "g() + g()" begins
>         1.2.1. Evaluation of one "g()" begins
>                1.2.1.1. y is incremented by one and its value is
>                         returned
>                1.2.1.2. ***SEQUENCE POINT***
>         1.2.2. Evaluation of one "g()" ends
>         1.2.3. Evaluation of the other "g()" begins
>                1.2.3.1. y is incremented by one and its value is
>                         returned
>                1.2.3.2. ***SEQUENCE POINT***
>         1.2.4. Evaluation of the other "g()" ends
>         1.2.5. The values of "g()" and "g()" are summed together
>    1.3. Evaluation of "g() + g()" ends
>    1.4. If "y" was not evaluated at 1.1, then it's evaluated here
>    1.5. The result of "g() + g()" is assigned to y
> 2. Evaluation of "y = g() + g()" ends
> 3. ***SEQUENCE POINT***

Thanks Joona. These were my thoughts exactly.

Quote:

> Notice, that by the time we have evaluated what we are assigning to
> y, we have already passed two sequence points, so it's clear that
> the evaluation of "g() + g()" must happen before the assignment.

Since you have to look into the function in the first place to even
consider that this might be UB, haven't there been four sequence points?
Two for the function calls and two for the return statements...
I'm not really sure if you can look at it this way though.

Quote:

> If g() was implemented as a macro:
> #define g() (++y)

> THEN we would have undefined behaviour. Macro expansion does not
> constitute a sequence point unless there is a sequence point inside
> what the macro expands to, and there is no sequence point in (++y).

I have to agree with that :)

--
Thomas



Sun, 26 Sep 2004 02:02:05 GMT  
 Most compilers can't do a simple sum



Quote:


> >> a version provided by my lecturer to demonstrate the dangers of
undefined
> >> behaviour is the following:

> >> /*invokes undefined behaviour*/

> >> #include <stdio.h>

> >> int x = 1;
> >> int y = 1;

> >> int g(void)
> >> {
> >>     return ++y;
> >> }

> >> int main(void)
> >> {
> >>     x = ++x + ++x;

> >>     y = g() + g();

> > Hmm, is this really UB? Since a statement always has at least one
> > sequence point. There is a sequence point after each modification
> > AFAIK...

> y = g() + g(); does NOT invoke undefined behaviour. A function call
> constitutes a sequence point. So what happens is:

[snip details]

Agreed - y is useful as a comparison to what happens to x. The value in x
after evaluation varies from implementation to implementation, but the value
in y does not.



Sun, 26 Sep 2004 02:05:14 GMT  
 Most compilers can't do a simple sum

Rowe) wrote in comp.lang.c:

Quote:
> I dreamed up a little sample C program today that seems
> to defeat practically every C compiler known to man.

> Here's the program:

> #include<stdio.h>
> void main()
> {
>   int x = 0, a = 0;
>   x = (++a) + (++a) + (++a);
>   printf("x = %d\n", x);
> }

> I believe the correct output should be:

> x = 6

> However...
> I and a couple of other folk have tried this out on various
> compilers and the results are:

> Visual C++ 6:      x = 7
> Visual C++.NET:    x = 9
> C++ Builder 4      x = 9
> GNU C compiler:    x = 7
> awk script (UNIX): x = 7
> acc (Solaris UNIX):x = 9
> IBM AIX compiler:  x = 7
> cc on HPUX:        x = 6

> We can see that most of the
> popular and most-commonly-used C compilers around at the
> moment are incapable of doing a simple sum.

> Are the authors of these compilers aware of this problem?
> Seems a bit worrying when C/C++ is so widely used in mission-critical
> applications.

Are you a troll, or just an ignoramus?

Seems a bit worrying when posters to comp.lang.c don't know that there
is no language "C/C++", and they are fscking idiots to boot.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq



Sun, 26 Sep 2004 11:22:56 GMT  
 Most compilers can't do a simple sum

Quote:

> #include<stdio.h>

and this line should read:-

 #include <stdio.h>

<snip lousy code>

Quote:
> Are the authors of these compilers aware of this problem?
> Seems a bit worrying when C/C++ is so widely used in mission-critical
> applications.

but hopefully not written by you

--
Nick Keighley

"It's probably not the quickest method around, but it uses plenty of
trees, and that's what counts."         -- Richard Heathfield



Sun, 26 Sep 2004 17:51:54 GMT  
 Most compilers can't do a simple sum

Quote:
>I dreamed up a little sample C program today that seems
>to defeat practically every C compiler known to man.

The first rule of thumb of programming is: if you don't get the result
you expect, don't suspect the hardware, OS or compiler to be faulty: the
bug is (with a *very* high probability) in your code.

Of course, hardware, OS or compiler bugs are not unheard of, just very
unlikely, compared to the probability that your code is broken.  But when
the same program fails to produce the expected results on multiple
platforms, insisting that the program is correct and the compilers are
broken is downright idiotic, unless you're intimately familiar with the
language specification (expect the people who wrote the compilers to be).

Your particular case is addressed by the FAQ, so, all you have achieved
with your post is presenting yourself as an arrogant ignorant who can't
be bothered to check the FAQ before posting.

Dan

P.S.  The validity of my first paragraph is limited to production
systems.  Things are quite different when programming on experimental
systems.  Experienced programmers who have to program on such systems
develop a special sense that allows them to quickly decide whether the
bug should be searched in their code, in the software tools or in the
hardware.
--
Dan Pop
DESY Zeuthen, RZ group



Sun, 26 Sep 2004 19:18:31 GMT  
 Most compilers can't do a simple sum

Quote:


> >I dreamed up a little sample C program today that seems
> >to defeat practically every C compiler known to man.

> The first rule of thumb of programming is: if you don't get the result
> you expect, don't suspect the hardware, OS or compiler to be faulty: the
> bug is (with a *very* high probability) in your code.

> Of course, hardware, OS or compiler bugs are not unheard of, just very
> unlikely, compared to the probability that your code is broken.  But when
> the same program fails to produce the expected results on multiple
> platforms, insisting that the program is correct and the compilers are
> broken is downright idiotic, unless you're intimately familiar with the
> language specification (expect the people who wrote the compilers to be).

> Your particular case is addressed by the FAQ, so, all you have achieved

So far, just fine.  An excellent answer.

Quote:
> with your post is presenting yourself as an arrogant ignorant who can't
> be bothered to check the FAQ before posting.

Then you destroy it utterly with this unnecessary vituperation,
and present yourself as the evil ogre of c.l.c.  Some of us, not
being Popes, have not been granted omniscience.  Consider it.

--

   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!



Sun, 26 Sep 2004 21:17:43 GMT  
 Most compilers can't do a simple sum

Quote:
>> Of course, hardware, OS or compiler bugs are not unheard of, just very
>> unlikely, compared to the probability that your code is broken.  But when
>> the same program fails to produce the expected results on multiple
>> platforms, insisting that the program is correct and the compilers are
>> broken is downright idiotic, unless you're intimately familiar with the
>> language specification (expect the people who wrote the compilers to be).

>> Your particular case is addressed by the FAQ, so, all you have achieved

> So far, just fine.  An excellent answer.

>> with your post is presenting yourself as an arrogant ignorant who can't
>> be bothered to check the FAQ before posting.

> Then you destroy it utterly with this unnecessary vituperation,
> and present yourself as the evil ogre of c.l.c.  Some of us, not
> being Popes, have not been granted omniscience.  Consider it.

Chuck, this is how Dan works. He teaches in a rough manner. We must all be
thick skinned when it comes to Dan's responses. He knows his C. After all,
did the OP really think a language as old as C with as many C compilers as
there are being rather old too would really{*filter*}up a sum?


Sun, 26 Sep 2004 21:22:39 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. C1001: INTERNAL COMPILER ERROR (compiler files 'msc1.cpp', line 2844)

2. C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 1794)

3. INTERNAL COMPILER ERROR - compiler file 'msc1.cpp', line 1794)

4. Simpler way of doing things in VC7 ATL?

5. Trouble doing simple things

6. PC Compiler Advice (About doing graphics)

7. what is this compiler doing? (resent)

8. what is this compiler doing? (resent)

9. Determining what canned preprocessor symbols are available

10. Beginner [Q] Using Canned File Open/Save dialog

11. Help with compiling a "canned" program

12. Canned Dialogs

 

 
Powered by phpBB® Forum Software