Need some explanation

[rahul8143]

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
void main()
{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

[Chris Dollin]

akarl wrote:

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

How come statements like these compile when the result is undefined? Is
it too hard for the compiler to figure out that it results in undefined
behavior?

In general, yes. (I believe GCC spots some simple cases.)

Consider:

... ++*bill + ++*ben ...

This is undefined if bill and ben point to the same location,
but well-defined [assuming no overflow ...] if they don't.

--
Chris "electric hedgehog" Dollin
It's called *extreme* programming, not *stupid* programming.

[Jirka Klaue]

John Bode:
....

Well, "undefined behavior" basically means the compiler is free to
handle the problem in any way it wants to. As soon as the Standard
mandates that the compiler issue a diagnostic or abort, the behavior is
no longer undefined.

If the undefined behavior is also a constraint violation a diagnostic
must be issued. (3.4.3#2, 5.1.1.3)

Jirka

[Ben Pfaff]

akarl <fu********@com hem.se> writes:

[...for something like x[i++] = i...]
How come statements like these compile when the result is undefined?
Is it too hard for the compiler to figure out that it results in
undefined behavior?

Sufficiently new versions of GCC will often warn about statements
like this.
--
Ben Pfaff
email: bl*@cs.stanford .edu
web: http://benpfaff.org

[Flash Gordon]

akarl wrote:

John Bode wrote:

ra*******@gmail .com wrote:
<snip>

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

How come statements like these compile when the result is undefined? Is
it too hard for the compiler to figure out that it results in undefined
behavior?

In these simple cases it is reasonably obvious there is undefined
behaviour. However, with
val = (*ptra)-- - --(*ptrb)
How can the compiler reliably determine whether there is undefined
behaviour or not?

So the standard does not require that compilers diagnose undefined
behaviour.

However, some compilers *will* diagnose *some* instances of undefined
behaviour if invoked with the correct switches. For example, the with
gcc -Wsequence-point catches a number of these cases, but it is not perfect.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[CBFalconer]

akarl wrote:

.... snip ...
How come statements like these compile when the result is
undefined? Is it too hard for the compiler to figure out that
it results in undefined behavior?

Why should it? It doesn't have to, because things are
syntactically correct. You are always allowed to use a safer
language, such as Pascal or Ada, if you wish. They have been
designed to have the necessary redundancy to detect such things. C
was designed to replace assembly language.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Peter Ammon]

akarl wrote:

John Bode wrote:

ra*******@gmail .com wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?

It's because you are invoking undefined behavior in both cases. Read
the following: http://www.eskimo.com/~scs/C-faq/s3.html

The expression i++ evaluates to the current value of i; the side affect
(i incremented by 1) is applied sometime before the next sequence
point, but it need not be immediately after the expression is
evaluated.

Similarly for ++i; it evaluates to the current value of i + 1, but i is
not necessarily incremented immediately.

There is no requirement on when the side affects are applied other than
it must happen before the next sequence point.

For example, given the statement

i = j++ + ++k;

the following sequence is possible:

t1 <- j
t2 <- k + 1
i <- t1 + t2
j <- j + 1
k <- k + 1

Same thing applies to your printf() statement; there's no sequence
point between the autoincrement/decrement expressions, so the behavior
is undefined, meaning the compiler can do anything it wants.

void main()

You mean int main(void). Strictly speaking, "void main()" is an error.

{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

How come statements like these compile when the result is undefined? Is
it too hard for the compiler to figure out that it results in undefined
behavior?

The OP's compiler, Turbo C, shipped in 1989 and isn't exactly the
pinnacle of modern compiler technology (no offense to the Borland
engineers who worked hard on it). Modern compilers will give much
better diagnostics.

To wit, gcc 4 catches all the errors in that code when you turn on
maximum warnings.

void main() {
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}

cc -O2 -W -Wall test.c
test.c:2: warning: return type of 'main' is not 'int'
test.c: In function 'main':
test.c:4: warning: implicit declaration of function 'printf'
test.c:4: warning: incompatible implicit declaration of built-in
function 'printf'
test.c:4: warning: operation on 'val' may be undefined
test.c:4: warning: operation on 'val' may be undefined
test.c:4: warning: operation on 'val' may be undefined

-Peter

--
Pull out a splinter to reply.

[Mark McIntyre]

On 8 Jul 2005 03:11:03 -0700, in comp.lang.c , ra*******@gmail .com
wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
void main()
main must return an int - void main() is illegal C code.

(snip example of undefined behaviour which is explained in the FAQ)
2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

This is a FAQ. Please read the FAQ, starting with 3.1.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Chris Croughton]

On Thu, 14 Jul 2005 11:35:18 +0100, Mark McIntyre
<ma**********@s pamcop.net> wrote:

On 8 Jul 2005 03:11:03 -0700, in comp.lang.c , ra*******@gmail .com
wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
void main()

main must return an int - void main() is illegal C code.

It isn't 'illegal' (the only place that word is used in the standard is
in the context of an "illegal instruction" raising a signal). It is
implementation defined whether it is permitted in a hosted environment;
in a freestanding environment it may not even describe the entry point
of the program, and if it does whether it is a valid definition is
implementation defined.

I do hope that no government makes certain C code illegal...

Chris C

[Walter Roberson]

In article <sl************ ******@ccserver .keris.net>,
Chris Croughton <ch***@keristor .net> wrote:
:I do hope that no government makes certain C code illegal...

Cryptography, DVD decoders, viruses...
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

[osmium]

"Chris Croughton" writes:

I do hope that no government makes certain C code illegal...

Good luck on your campaign to get programmers to speak English. You should
not expect quick results.