Need some explanation

R

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;
 
S

Suman

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?
#include said:
void main()
is not a portable standard definition for main, use:
int main(/*int argc, char **argv*/)
{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
/*falling off main, is a rather recent addition C99 onwards, AFAIK,
hence*/
return 0;
}
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5
The order in which the arguments to printf are evaluated is *not* the
same across different compiler/system pairs.
2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;
You might like to read the FAQ, and some stuff on side-effects and
sequence points.
 
S

Suman

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;

Goto http://www.eskimo.com/~scs/C-faq/s3.html.
 
A

akarl

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;

In the first case the behavior is undefined (evaluation order of
function parameters). The statement in (2) is very hard to read and
should (in practice) be rewritten into something more comprehensible.

Moreover:

- `void main()' is not a valid ANSI C signature for the main function.

- You have not included stdio.h

- Your coding style is inconsistent and the indentation is strange to
say the least.
 
J

John Bode

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.
 
C

Christian Kandeler

akarl said:
In the first case the behavior is undefined (evaluation order of
function parameters). The statement in (2) is very hard to read and
should (in practice) be rewritten into something more comprehensible.

The second case is also undefined, for the same reason the first one is
(repeated modifications of an object without an intervening sequence
point).


Christian
 
C

CBFalconer

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;

Get your C book or the standard and read up on sequence points
and/or parameter evaluation order. This is elementary. And if you
really mean C++ this is not the place.
 
A

akarl

John said:
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.




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

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?
 
R

Richard Bos

akarl said:
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 a simple case like this, perhaps not; but in the general case, yes.

Richard
 
J

John Bode

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


How come statements like these compile when the result is undefined?

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.
Is
it too hard for the compiler to figure out that it results in undefined
behavior?

I'm not a compiler writer by trade, so I can't say for sure. In the
obvious case (i = i++), it shouldn't be too hard. But imagine a case
like this:

foo.c
-----------------------
int foo(int *p, int *q)
{
return (*p)++ + ++(*q);
}

main.c
-----------------------
extern int foo(int *p, int *q);

int main(void)
{
int i, *j, *k;
int x;

k = &i;
i = 5;
j = k;

x = foo(j, k);
return 0;
}

Not only is i aliased by pointers, the foo() function is compiled
separately from the main() function. There's simply no way to detect
that i is being modified more than once between sequence points at
compile time.

Situations like that would be impossible to guard against. That's why
the Standard leaves the behavior "undefined"; there's simply no good
way to catch all instances of this problem at compile time, so no
requirement is placed on the compiler implementor to do so.
 
C

Chris Dollin

akarl said:
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.
 
J

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
 
B

Ben Pfaff

akarl said:
[...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.
 
F

Flash Gordon

akarl said:
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.
 
C

CBFalconer

akarl said:
.... 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.
 
P

Peter Ammon

akarl said:
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
 
M

Mark McIntyre

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.
 
C

Chris Croughton

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
 
O

osmium

Chris Croughton said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top