Why I get this output ?

[JohnF]

This is the code I used

Code: [Select]

#include <stdio.h>

int main(void)
{
int i = 7;
printf("%d\n", i++ * i++);

    return 0;
}

PellesC prints 56 VC6 prints 49

EDIT:

And this

Code: [Select]

#include <stdio.h>

int main(void)
{
int i = 1;
printf("%d%d%d\n", i++, i++, i++);
    return 0;
}

PellesC gives 321 - VC6 gives 111

John

[TimoVJL]

Code: [Select]

pocc 2.50> 3 3 1 2 2 1
gcc 3.4.5 3 3 1 2 2 1
gcc 4.5.1 3 3 1 2 3 3
gcc 4.6.1 3 3 1 2 3 3
dmc 8.51n 3 3 1 2 2 1
msvc4std 3 3 1 2 3 3
msvc5 2 2 1 2 2 1
msvc6sp6 2 2 1 2 2 1
msvc 2003 2 2 1 2 2 2
msvc 2005 2 2 1 2 2 2
msvc 2008 2 2 1 2 2 2
msvc 2010sp1 2 2 1 2 2 2
msvc 2012 2 2 1 2 2 2

[CommonTater]

Thanks to all of you very much....this discussion helped me a lot.
CommonTater specially thank u very much .... the thing that u have said is given slightly here...in sections 3.4.3, 3.4.4 and 6.5 of the following pdf.
http://www.linux2you.dk/JTC1/SC22/WG14/www/docs/n1336.pdf

Rather a lot has been written about undefined behaviour... spend a little time on google searching it out.  I got thousands of hits for "undefined behaviour C". 

Your code snippet is an example of undefined behaviour that is tripped up by the way the printf() function is written in different libraries.  As Timo's list clearly shows not only is the result different for different compilers, it can change for different versions of the same compiler.

The problem is that c solves things in blocks.  A forumula such as  B = A++ / A--  can be interpreted differently by different compilers.  One might reasonably expect that B will always equal 1 but it may not... one compiler (or version) will solve it as B = (A/A); A+1; A-1;  another may solve it as B= ((A + 1) / (A - 1)) or  and so on.  While your present compiler may give you consistent results, simply recompiling with a new version of the same compiler may crash your programs.

Another curiosity for you to explore would be this...

Code: [Select]

A = 1;
printf("A = %d ", A++);
A = 1;
printf("A = %d ", ++A);
A = 1;
printf("A = %d ", A++);
printf("A = %d ", ++A);
This should print ... 1 2 1 3 .... and since you're only doing one change per block it should give consistent results on all compilers.

I'm wondering where you got that snippet... 
Was it presented to you as valid code?

[boral]

I'm wondering where you got that snippet... 
Was it presented to you as valid code?

I was reading the calling convention of C functions from the book "Let us C" by Yashwant Kanetkar, 5th edition.....there the following program was given as an example:
#include<stdio.h>
main()
{
int  a = 1 ;
printf ( "%d %d %d", a, ++a, a++ ) ;
}
I desired to do a little research by changing the program a little to see how the flow of control actually works ... and hence by chance I got that snippet...being confused with the output , I posted the problem here.

@ timovjl and JohnF, thank you very much for your research results.

[CommonTater]

I'm wondering where you got that snippet... 
Was it presented to you as valid code?

I was reading the calling convention of C functions from the book "Let us C" by Yashwant Kanetkar, 5th edition.....there the following program was given as an example:
#include<stdio.h>
main()
{
int  a = 1 ;
printf ( "%d %d %d", a, ++a, a++ ) ;
}
I desired to do a little research by changing the program a little to see how the flow of control actually works ... and hence by chance I got that snippet...being confused with the output , I posted the problem here.

@ timovjl and JohnF, thank you very much for your research results.

Well, my friend, all I can suggest is that you need to pick a different book ... if any example shows multiple changes to a single variable in the same bracketed block it's likely to end up being yet another "Undefined Behaviour".  While I haven't said so in one sentence, it should be clear that this is to be avoided since it directly impacts the reliability of your software.

Perhaps this point is not stressed enough with beginners ... it sure wasn't when I started in C... but there are many things you can do with software that should work, look like they'll work, but somehow just never do.  I will be the first to tell you there's no completely wrong way to write code.  If it works, it works...  but what happens when it appears to work but doesn't?  That's a whole horse of a different colour.

This whole "Undefined Behaviours" thing is best summarized by a tagline I saw on another forum...
"Unedefined behaviour means your program will work perfectly, until you show it to your customer."
 
Your curiosity is to be commended. Most progress in life comes from those who "think outside the box" and explore radical and different ideas. Nobody ever made a "great leap" by following the rules
 
I'm hoping you've learned "Edison's Quest" from this... He was once challenged on the time and effort going into the development of the electric light bulb and responded: "No gentlemen I do not know how to make an electic light bulb, but I have discovered dozens of ways not to make one."  ...
 
Sometimes it's just as important to know what does not work.
 

[boral]

Well, my friend, all I can suggest is that you need to pick a different book
 

Can u suggest a good book on C [ for beginners] and if possible give the download link.

[CommonTater]

Boral ... give this a read ... http://forum.pellesc.de/index.php?topic=4644.0

Plus, there are many other resources and books that are very credible. 
I'm sure the others here can help you with their own recommendations. 

Also, please note, there's a lot of "stuff" that only comes from experience.  You should count your recent boggle over the results from that one small snippet as just that... part of the learning curve.

FWIW ... I took a look at the online version of "Let us C" ... and the first program on page 14 already set off my "spider sense" telling me it's not based on C-99 or C-11 standards, but most probably comes from Turbo C which is now wildly outdated.  Then on page 15 it actually recommends Turbo C ... which is an old MS-DOS compiler.  MS-DOS has been a dead horse for over 15 years...

Code: [Select]

/* Calculation of simple interest */
/* Author gekay  Date: 25/05/2004 */
main( )
{
       int   p, n ;
       float   r, si ; 
 
       p = 1000 ;
       n = 3 ;
       r = 8.5 ;
 
       /* formula for simple interest */
       si = p * n * r / 100 ;   
 
       printf ( "%f" , si ) ;
}   

There are a few problems with this code...
1) The older form main() used widely in Turbo C has long been replaced by int main (void) and although not manditory you probably should use int _cdecl main (void) (especially when including windows API headers).  POCC (Pelles C compiler) should have been warning you about this from the beginning.
 
2) Windows expects a returned value from programs when they exit. If one is not given, the value seen by Windows can be any random number that happens to be in memory.  It is considered that a return value of 0 means ERROR_SUCCESS, but if your program either encounters problems or is to be used with the IF ERRORLEVEL feature of batch files, the numerical value returned can be significant.  Thus your main function should always end with a return statement... Most often return 0; is acceptable but in some cases you may want to create a specific value for it to return as in return MyValue; or you may want to return the system's own internal error value as in return GetLastError();
 
3) Also note that printf() is called without including any header files... This is Turbo C specific, since the TC IDE auto-includes stdio, stdlib and conio for you... others do not.
 
So in contrast to what many older texts will show you the correct minimal program for c-99 or c-11 is like this...

Code: [Select]

#include <stdio.h>
 
int main (void)
  {
    printf("Hello World!\n");
 
    return 0;
  }

There are a great many manuals that were written before the new standards came into effect and a number of writers who haven't kept up.  So a bit of caution when picking your texts is advised. 

And, before you ask ... I'm fully aware that as a beginner nobody could expect you to know any of this.  I didn't.

 

[Bitbeisser]

FWIW ... I took a look at the online version of "Let us C" ... and the first program on page 14 already set off my "spider sense" telling me it's not based on C-99 or C-11 standards, but most probably comes from Turbo C which is now wildly outdated.  Then on page 15 it actually recommends Turbo C ... which is an old MS-DOS compiler.  MS-DOS has been a dead horse for over 15 years...

That has absolutely no bearing here at all...

There are a few problems with this code...
1) The older form main() used widely in Turbo C has long been replaced by int main (void) and although not manditory you probably should use int _cdecl main (void) (especially when including windows API headers).  POCC (Pelles C compiler) should have been warning you about this from the beginning.

Even Turbo C will give a warning (unless, just like with Pelle's C, this warning is intentionally disabled).

2) Windows expects a returned value from programs when they exit. If one is not given, the value seen by Windows can be any random number that happens to be in memory.  It is considered that a return value of 0 means ERROR_SUCCESS, but if your program either encounters problems or is to be used with the IF ERRORLEVEL feature of batch files, the numerical value returned can be significant.  Thus your main function should always end with a return statement... Most often return 0; is acceptable but in some cases you may want to create a specific value for it to return as in return MyValue; or you may want to return the system's own internal error value as in return GetLastError();

Windows itself gives a small rodents posterior about the return code.
Is the more DOS based command processor that is actually querying the return code... ;-)

3) Also note that printf() is called without including any header files... This is Turbo C specific, since the TC IDE auto-includes stdio, stdlib and conio for you... others do not.

Sorry, Tater, nothing personal, but this is utter nonsense....
You will get warnings about undefined external (and subsequently assuming 'int') as does any other C compiler...

So in contrast to what many older texts will show you the correct minimal program for c-99 or c-11 is like this...

Code: [Select]

#include <stdio.h>
 
int main (void)
  {
    printf("Hello World!\n");
 
    return 0;
  }


Which Turbo C will also happily compile... 

There are a great many manuals that were written before the new standards came into effect and a number of writers who haven't kept up.  So a bit of caution when picking your texts is advised. 

And, before you ask ... I'm fully aware that as a beginner nobody could expect you to know any of this.  I didn't.

If there's something to complain about the book, then it is the writing style of the author (and the publisher even going through with this), in particular for a book that has been published in 2005, long after the use of ANSI C (as in C89/C90).

Ralf

[CommonTater]

If there's something to complain about the book, then it is the writing style of the author (and the publisher even going through with this), in particular for a book that has been published in 2005, long after the use of ANSI C (as in C89/C90).

Hi Ralf ...

No worries about the critique of my message ... I can deal with it...

However, the earliest versions of Turbo C did not give the warnings we get now. Yes it would compile it my way just fine... but the point is that it didn't warn you which lead to the formation of some sketchy programming practices --including the ignoring of warnings-- that found their way into a good number of books and, are still actively taught in some places. (most notably in India where the book originates)
 
The importance of the return value should not be underestimated... It is the value used by GetExitCodeThread() and other API functions that deal with child processes as well as in CMD.EXE for it's IF ERRORLEVEL function.  The problem is that memory is set aside for it when you start the process and if nothing is written to that memory address by the return keyword any program that relies on that value for anything is very likely to falsely report some very strange errors.  More than once I've watched batch files misbehave because an expected return value is not specified. So it's pretty clear that no matter how much page space Microsoft gives it, the return value from Main (or WinMain) is necessary to be fully Windows compiliant.
 
The real problem here, as you point out, is that many writers and programmers have not kept up and still continue teaching according to earlier standards, or the lack of standards.
 
So we agree, it's not a great book... but obviously for somewhat differing reasons.
 

[Bitbeisser]

If there's something to complain about the book, then it is the writing style of the author (and the publisher even going through with this), in particular for a book that has been published in 2005, long after the use of ANSI C (as in C89/C90).

Hi Ralf ...

No worries about the critique of my message ... I can deal with it...

Just wanted to make sure... 

However, the earliest versions of Turbo C did not give the warnings we get now. Yes it would compile it my way just fine... but the point is that it didn't warn you which lead to the formation of some sketchy programming practices --including the ignoring of warnings-- that found their way into a good number of books and, are still actively taught in some places. (most notably in India where the book originates)

Sorry, but that simply isn't right. All versions of Turbo/Borland C had those warnings, it's solely up to the user to ignore those. (I just took the screenshot of that warning from a BC++3.1 compiler, as that is what I have installed on this very same Windows XP PC).
The actual problem is that people as the mentioned author as late as 2005 still promoting/teaching pre-ANSI style of C, not the choice of compiler they use/recommend!

The importance of the return value should not be underestimated... It is the value used by GetExitCodeThread() and other API functions that deal with child processes as well as in CMD.EXE for it's IF ERRORLEVEL function.  The problem is that memory is set aside for it when you start the process and if nothing is written to that memory address by the return keyword any program that relies on that value for anything is very likely to falsely report some very strange errors.  More than once I've watched batch files misbehave because an expected return value is not specified. So it's pretty clear that no matter how much page space Microsoft gives it, the return value from Main (or WinMain) is necessary to be fully Windows compiliant.

My slight jab at here was more in reference of you demeaning the use of a DOS compiler, which IMHO is actually the best option for a complete real C newbie. You can learn must easier the very basics of C, with all the Windows/GUI fluff.
Just look at an empty template for a "compliant" Win32 program generated by Pelle's C, that is enough to scare the bejezus out of newbie!

The real problem here, as you point out, is that many writers and programmers have not kept up and still continue teaching according to earlier standards, or the lack of standards.
 
So we agree, it's not a great book... but obviously for somewhat differing reasons.

That a book like this is published in this way, that is the only problem. ANSI style C, with the focus on properly declaring functions and procedure, as well as variables (the only thing where anything newer than C89/C90 would be of any help for a newbie in C99 or C11) has been around since 1990, that's +22 years. Each and every compiler, for pretty much any OS, has supported this since then.

Ralf

[CommonTater]

Just wanted to make sure... 

Really, how long have we been friends on here?  And you still think me that frail?  What can I say...

Sorry, but that simply isn't right. All versions of Turbo/Borland C had those warnings, it's solely up to the user to ignore those. (I just took the screenshot of that warning from a BC++3.1 compiler, as that is what I have installed on this very same Windows XP PC).

My first experience with C was on Turbo C ... part of a combo pack Borland had out in Canada... Pascal + C for 30% off, if memory serves.  I didn't know the first darned thing about C at that point and it may be faulty memory but I don't recall it ever warning me about main or the return value...  But, hey, that was a long time ago...

The actual problem is that people as the mentioned author as late as 2005 still promoting/teaching pre-ANSI style of C, not the choice of compiler they use/recommend!

Ralf, it's not about the compiler per se... It's about the AGE of the compiler.  In case you didn't knotice C has changed a little since then.  The term "pre-ANSI" sums it up very nicely.

My slight jab at here was more in reference of you demeaning the use of a DOS compiler, which IMHO is actually the best option for a complete real C newbie. You can learn must easier the very basics of C, with all the Windows/GUI fluff.

Pelles C will compile the simple little 10 line "hello world" just fine and run it in a shell window so I'm just a little confused what your issue is. 
 
I'm not defending Pelles C (as you probably know I'm one of the first to point out it's problems, when relevent) and I'm not bashing Turbo C ... I'm talking about starting someone off in a compliant atmosphere that is based on the standards they will most likely be required to work in later.  It's pretty simple actually... by starting off with main() --for a trivial example-- you are teaching a bad habit that later has to be broken... That's not education, it's a minor form of sabotage.
 
On other forums where I've talked about programming, one of the biggest issues C students had was having to unlearn what school taught them so they could learn proper techniques for their careers.  As I've ponited out this was a particular problem with students from India when they discovered, all of a sudden, that much of what they'd been shown was actually wrong by modern standards.
 
All I'm saying is start them off right... Let the old ways die the death they deserve.

Just look at an empty template for a "compliant" Win32 program generated by Pelle's C, that is enough to scare the bejezus out of newbie!

Not all Pelles C programs are Win32 GUI aps, Ralf... and, frankly, if they find it frightening rather than intriquiing, they just might be working on the wrong career path to begin with.  My first real C program was in GUI mode. I never wrote console programs before joining here...

In fact, one might opine that including things like "compatibility names" and conio.h Pelles C intends to directly replace Turbo C with an up to date compiler... which is actually a good thing.

You were direct with me... now it's my turn.
 
I disagree with your approach for the simple reason that you are essentially asking someone to learn "the old way" then leaving them to re-learn it all "the new way"... I agree with you completely about learning general principles, variables, loops, functions etc right up front... but I can't agree they should have to do it on some dusty old MS-DOS machine.
 
As I see it, we should start them off on console programs, "the new way" and elminate the confusion of transitioning to standards simply because they're already there.  Windows console programming is close enough to MS-DOS there's no reason to run DOS anymore... it's a dead horse... let the glue factory have it.
 
FWIW... I do get your defense of the tools you like.  But please know that in this case I don't have a favorite hammer... if a better one comes along, I'm gonna dump the old one like a hot rock and IMO a programmer who doesn't isn't really doing his job.
 
No offense my friend... but perhaps we should just agree to disagree on this one!
 

[Bitbeisser]

My first experience with C was on Turbo C ... part of a combo pack Borland had out in Canada... Pascal + C for 30% off, if memory serves.  I didn't know the first darned thing about C at that point and it may be faulty memory but I don't recall it ever warning me about main or the return value...  But, hey, that was a long time ago...

Right, I switched from DeSmet C to Turbo C when it first came out in '87, as it already supported what was to become ANSI C in '89. Have used it in all it's incarnations ever since...
(DeSmet came out with a ANSI compiler after Turbo C came out and that is likely the main reason for it's demise, though it is now available as the only 16bit compiler under GPL, since 2005)

The actual problem is that people as the mentioned author as late as 2005 still promoting/teaching pre-ANSI style of C, not the choice of compiler they use/recommend!

Ralf, it's not about the compiler per se... It's about the AGE of the compiler.  In case you didn't knotice C has changed a little since then.  The term "pre-ANSI" sums it up very nicely.

But pre-ANSI means pre-Turbo C. And we are talking +25 years here. The oldest version of Turbo C you can get your hands on legally is Turbo C 2.01, that's from 1990, when ANSI C was already official...

Pelles C will compile the simple little 10 line "hello world" just fine and run it in a shell window so I'm just a little confused what your issue is. 

You started to elude to the Win API, which is for someone learning the first steps (and pecularities) in C totally irrelevant. And just for the record, a pre-ANSI C compiler will compile that same program just as fine...

Again, it's a matter of how you use it/teach it. Not a matter of the compiler effectively being used...

I'm talking about starting someone off in a compliant atmosphere that is based on the standards they will most likely be required to work in later.  It's pretty simple actually... by starting off with main() --for a trivial example-- you are teaching a bad habit that later has to be broken... That's not education, it's a minor form of sabotage.

We do not have an argument here... 

All I'm saying is start them off right... Let the old ways die the death they deserve.

That refers to the method of programming, but does not necessarily limit the tools used...

In fact, one might opine that including things like "compatibility names" and conio.h Pelles C intends to directly replace Turbo C with an up to date compiler... which is actually a good thing.

I think you are making bad references here. Nobody forces you in Turbo C to use conio.h or any of the other DOS specific extensions/headers/libraries. You can stick to "plain C" just as fine...

I disagree with your approach for the simple reason that you are essentially asking someone to learn "the old way" then leaving them to re-learn it all "the new way"... I agree with you completely about learning general principles, variables, loops, functions etc right up front... but I can't agree they should have to do it on some dusty old MS-DOS machine.

For one, what exactly do you define as "the old way" and "the new way"?
As far as learning the basics of C, it doesn't matter what you are using, even if it is a "dusty old MS-DOS machine.

As I see it, we should start them off on console programs, "the new way" and elminate the confusion of transitioning to standards simply because they're already there.

Now you are confusing me. What in regards to console programs is so "new" that you can't do this with whatever C compiler is out there, on whatever OS?

Windows console programming is close enough to MS-DOS there's no reason to run DOS anymore... it's a dead horse... let the glue factory have it.

Well, if I didn't know you are Canadian, I would say "typical American arrogance and ignorance". I think it is a huge mistake to assume that each and everyone, everywhere in the world has access to the latest multi-core CPU with dozens of GB of RAM...
Not to mention that C has the reputation of being the language of choice for a lot of embedded stuff, with environments as restrictive as DOS (or even worse).

FWIW... I do get your defense of the tools you like.  But please know that in this case I don't have a favorite hammer... if a better one comes along, I'm gonna dump the old one like a hot rock and IMO a programmer who doesn't isn't really doing his job.

I just didn't agree with your assessment that the use of MS-DOS and Turbo C in that particular book mentioned was a reason to discourage it's use. It's the method of teaching C, using those tools, that is highly questionable.
Btw, when I tried to find some more info about that book/author, I found info that the newer editions at least include OpenWatcom as their reference compiler, did however not see any sample code of that edition (10th) so see if he's still using K&R style coding in the book...

Ralf

[CommonTater]

Now you are confusing me. What in regards to console programs is so "new" that you can't do this with whatever C compiler is out there, on whatever OS?

Nothing ... that's my entire point, Ralf ... if you can do these things in a current (or at least non-ancient) environment, why wouldn't you?  You're going to have to get yourself up to date sometime... might as well start out that way.
 
I almost hear you saying "They should learn it this way because I did." but I doubt that's what youactually  mean.

Windows console programming is close enough to MS-DOS there's no reason to run DOS anymore... it's a dead horse... let the glue factory have it.

Well, if I didn't know you are Canadian, I would say "typical American arrogance and ignorance". I think it is a huge mistake to assume that each and everyone, everywhere in the world has access to the latest multi-core CPU with dozens of GB of RAM...

We're far enough along with windows --more than 12 years for Win32-- that virtually everyone should be running one version or another. 
 
I found it really hilarious when this huge thread emerged on another forum about getting Vista to run a command shell Full Screen so they could use their 16 bit Dos compilers in wow32... My question, which went totally unanswered was "Why don't you download one of the free 32 bit compilers?" ...  It seems they'd been issued laptops with Vista but their Comp Sci professor was teaching with Turbo C ... on (get this) Floppy disks!  Yep, you heard me... floppies!
 
They don't even make diskettes anymore... so there was this big fuss about getting drives and extra disks...
 

Not to mention that C has the reputation of being the language of choice for a lot of embedded stuff, with environments as restrictive as DOS (or even worse).

And these are dialects of C that are very upfront about being dialects of C...

I just didn't agree with your assessment that the use of MS-DOS and Turbo C in that particular book mentioned was a reason to discourage it's use. It's the method of teaching C, using those tools, that is highly questionable.

Yes I agree... but then we go back to stupid situations like trying to backdate Vista by 15 years rather than simply getting an up to date compiler. 
 
Then of course there was the whole boondoggle about people trying to get BGI DOS-MODE graphics running on windows systems... That whole episode was pretty pathetic... and the saddest part was that none of the students appeared to understand just how badly outdated their education was. 
 
About the only thing they could carry forward from that course was basic concept... and quite honestly I saw little evidence of that actually being taught. It is the teaching methods that are the real problem, but almost always this seems to hover around Turbo C ... on floppy disks, no less...
 
 

[TimoVJL]

Code: [Select]

/* Calculation of simple interest */
/* Author gekay  Date: 25/05/2004 */
main( )
{
       int   p, n ;
       float   r, si ; 
 
       p = 1000 ;
       n = 3 ;
       r = 8.5 ;
 
       /* formula for simple interest */
       si = p * n * r / 100 ;   
 
       printf ( "%f" , si ) ;
}TCC.EXE CALCINT.C

Code: [Select]

Turbo C  Version 2.01  Copyright (c) 1987, 1988 Borland International
calcint.c:
Turbo Link  Version 2.0  Copyright (c) 1987, 1988 Borland International


Available memory 456558


[CommonTater]

Hi Timo ....

Is there any compiler you don't have?

So what are you showing us?  I see a distinct lack of warnings there...