++ devils

Eric said:

Ben Pfaff wrote:
int main(void){char
p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int
putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof
p-1;putchar(p[i]\ );}return 0;}

Just curious what this is supposed to do, i compiled and ran it and i get:
Itrs.Ylmreanx wbTVdWjsu

Which means nothing to me...

Let's take it apart, then - ruthlessly re-organising the code for clarity
(sorry, Ben!). At no point (and I think this is important) will we assume
that Ben is assuming ASCII.

int main(void)
{
char p[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz. \n";
char *q = "kl BIcNBFr.NKEzjwCIxNJC";
int i=sizeof p/2;
char *strchr();
int putchar();
while(*q)
{
i += strchr(p, *q++) - p;
if(i >= (int)sizeof p)
{
i -= sizeof p-1;
}
putchar(p[i]);
}
return 0;
}

Now we'll get rid of those prototypes, by including the relevant headers:

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

int main(void)
{
char p[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz. \n";
char *q = "kl BIcNBFr.NKEzjwCIxNJC";
int i=sizeof p/2;

while(*q)
{
i += strchr(p, *q++) - p;
if(i >= (int)sizeof p)
{
i -= sizeof p - 1;
}
putchar(p[i]);
}
return 0;
}

Clearly p is an alphabet, which leads me to think Ben is being very mindful
of portability here. So his q points to some kind of indexing mechanism,
which will be used to select letters from the alphabet.

His first processing step is to set i to 28 (i.e. the size of p, divided by
2).

Now he loops through the characters in the string literal pointed to by q.

The first of these is 'k'. He calls strchr to find out how far into p[] 'k'
can be found. (He bumps q at the same time, ready to go round again.)

k is at offset 37, so he adds 37 to i, making it 65. He now subtracts the
number of characters in the alphabet array - i.e. 55. This leaves 10. He
now displays the 10th character of his alphabet, which is 'J'.

Now he goes round again, this time looking for the offset of 'l' in p[].
This is 38, so he adds this to i, making 48. The 48th character in p[] is
'u', so he displays 'u', and goes round again.

So we have the pattern. He is overloading p[] quite horribly :-) by using it
not just as a repository of displayable characters but also as a catalyst
for converting a number into a letter, for obfuscatory reasons.

If we use his technique to construct a different message, it may help you to
understand the program.

Message: "clc rocks\n"

We have this skeleton program:

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

int main(void)
{
char p[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz. \n";

char *q goes here, but we aren't yet sure what to put here.

int i=sizeof p/2;

while(*q)
{
i += strchr(p, *q++) - p;
if(i >= (int)sizeof p)
{
i -= sizeof p - 1;
}
putchar(p[i]);
}
return 0;
}

We want to start off with a 'c', so we count from offset 28 to the letter
'c'. This happens to be 0 (by chance, that's all). Offset 0 in p[] is 'A',
so the first letter in our indexing mechanism is 'A'. The next letter we
want is 'l', which is 9 characters along from 'c', so we want to move 9
letters further along the alphabet from our current 'A' position: that
leads us to 'J'.

Continuing in this manner, we end up with this string:

char *q="AJuZt.rIIK";

Plug it in:

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

int main(void)
{
char p[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz. \n";

char *q="AJuZt.rIIK";

int i=sizeof p/2;

while(*q)
{
i += strchr(p, *q++) - p;
if(i >= (int)sizeof p)
{
i -= sizeof p - 1;
}
putchar(p[i]);
}
return 0;
}

Recompile, and run it:

$ ./foo
clc rocks
$
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

May 21 '06 #15

CBFalconer

muttaa wrote:

Ok,what should i do if i am asked such sort of questions in my
interview or written exams in the future?

You should first learn to include adequate context in your
articles. For means to do so on the insipid google interface to
usenet, see my sig. below.

If asked such question the answer is "undefined behaviour". It may
be the asker doesn't agree with that, and is an idiot.

--
"If you want to post a followup via groups.google.com, 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
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

May 22 '06 #16

Joe Smith

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:aI********************@bt.com...

Eric said:
Ben Pfaff wrote:
int main(void){char
p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int
putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof
p-1;putchar(p[i]\ );}return 0;}

Just curious what this is supposed to do, i compiled and ran it and i
get:
Itrs.Ylmreanx wbTVdWjsu

Which means nothing to me...

Let's take it apart, then - ruthlessly re-organising the code for clarity
(sorry, Ben!). At no point (and I think this is important) will we assume
that Ben is assuming ASCII.

int main(void)
{
char p[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz. \n";
char *q = "kl BIcNBFr.NKEzjwCIxNJC";
int i=sizeof p/2;
char *strchr();
int putchar();
while(*q)
{
i += strchr(p, *q++) - p;
if(i >= (int)sizeof p)
{
i -= sizeof p-1;
}
putchar(p[i]);
}
return 0;
}

Now we'll get rid of those prototypes, by including the relevant headers:

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

int main(void)
{
char p[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz. \n";
char *q = "kl BIcNBFr.NKEzjwCIxNJC";
int i=sizeof p/2;

while(*q)
{
i += strchr(p, *q++) - p;
if(i >= (int)sizeof p)
{
i -= sizeof p - 1;
}
putchar(p[i]);
}
return 0;
}

Clearly p is an alphabet, which leads me to think Ben is being very
mindful
of portability here. So his q points to some kind of indexing mechanism,
which will be used to select letters from the alphabet.

His first processing step is to set i to 28 (i.e. the size of p, divided
by
2).

Now he loops through the characters in the string literal pointed to by q.

The first of these is 'k'. He calls strchr to find out how far into p[]
'k'
can be found. (He bumps q at the same time, ready to go round again.)

k is at offset 37, so he adds 37 to i, making it 65. He now subtracts the
number of characters in the alphabet array - i.e. 55. This leaves 10. He
now displays the 10th character of his alphabet, which is 'J'.

Now he goes round again, this time looking for the offset of 'l' in p[].
This is 38, so he adds this to i, making 48. The 48th character in p[] is
'u', so he displays 'u', and goes round again.

So we have the pattern. He is overloading p[] quite horribly :-) by using
it
not just as a repository of displayable characters but also as a catalyst
for converting a number into a letter, for obfuscatory reasons.

If we use his technique to construct a different message, it may help you
to
understand the program.

Message: "clc rocks\n"

We have this skeleton program:

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

int main(void)
{
char p[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz. \n";

char *q goes here, but we aren't yet sure what to put here.

int i=sizeof p/2;

while(*q)
{
i += strchr(p, *q++) - p;
if(i >= (int)sizeof p)
{
i -= sizeof p - 1;
}
putchar(p[i]);
}
return 0;
}

We want to start off with a 'c', so we count from offset 28 to the letter
'c'. This happens to be 0 (by chance, that's all). Offset 0 in p[] is 'A',
so the first letter in our indexing mechanism is 'A'. The next letter we
want is 'l', which is 9 characters along from 'c', so we want to move 9
letters further along the alphabet from our current 'A' position: that
leads us to 'J'.

Continuing in this manner, we end up with this string:

char *q="AJuZt.rIIK";

Plug it in:

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

int main(void)
{
char p[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz. \n";

char *q="AJuZt.rIIK";

int i=sizeof p/2;

while(*q)
{
i += strchr(p, *q++) - p;
if(i >= (int)sizeof p)
{
i -= sizeof p - 1;
}
putchar(p[i]);
}
return 0;
}

Recompile, and run it:

I'm at a bit of a roadblock in taking this a step further. This choice of
string literal:
char *q = "dYLsIKJAAB";
is to yield "Calais " with 2 spaces and a newline. BTW, the reason that p
has order 56 is not that there 56 things between the quotes. I was quite
certain an hour ago that I could permute the elements of p so as to make the
output instead print "Normandy" with a newline. My certainty has been
deflated by my failure to find a suitable p. joe

May 22 '06 #17

Robert Gamble wrote:

muttaa wrote:
Hello all,

My doubt is going to be so primitive that i ask you all to forgive me
beforehand....

Here's the code snippet:

int main()
{
int x=5;
x=x++ + ++x;
printf("%d",x);
return 0;
}

I know that the printf is going to print some value of x which none can
predict accurately for all times for all compilers....However,why i ask
this is because such type of questions keep appearing in a lot of
Question Papers....

The behavior is undefined, x can now be any value. I would suggest you
read our FAQ at <http://c-faq.com/expr/index.html>, start with question
3.2.

Robert Gamble

why programming languages have undefined behavior?

May 22 '06 #18

v4vijayakumar opined:

Robert Gamble wrote:
muttaa wrote:
<snip>

> x=x++ + ++x;

<snip>
The behavior is undefined, x can now be any value. I would suggest
you read our FAQ at <http://c-faq.com/expr/index.html>, start with
question 3.2.

why programming languages have undefined behavior?

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

--
...you could spend *all day* customizing the title bar. Believe me. I
speak from experience."
(By Matt Welsh)

<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

May 22 '06 #19

Vladimir Oka wrote:

v4vijayakumar opined:

Robert Gamble wrote:
muttaa wrote:
<snip>
x=x++ + ++x;
<snip>
The behavior is undefined, x can now be any value. I would suggest
you read our FAQ at <http://c-faq.com/expr/index.html>, start with
question 3.2.

why programming languages have undefined behavior?

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

<snip>

It seems that these are problems(?!) with 'sequence points'. When
operands (x++) could be potential expressions then why don't introduce
more 'sequence points'?! any performance issues?!

May 22 '06 #20

v4vijayakumar wrote:

Vladimir Oka wrote:
v4vijayakumar opined:

Robert Gamble wrote:
> muttaa wrote:

<snip>
> > x=x++ + ++x;

<snip>
> The behavior is undefined, x can now be any value. I would suggest
> you read our FAQ at <http://c-faq.com/expr/index.html>, start with
> question 3.2.

why programming languages have undefined behavior?

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

<snip>

It seems that these are problems(?!) with 'sequence points'. When
operands (x++) could be potential expressions then why don't introduce
more 'sequence points'?! any performance issues?!

Why not indeed! Just break it down into easy understandable and weel
defined steps.

This will enable you to spell out the order of execution, and make sure
the result is repeatable. Any compiler worth its salt should optimise
this sort of calculation regardless of how you write it, so there
should be no performance penalty whatsoever. Also, do you really care
about the peroformance if you get the wrong result?

May 22 '06 #21

Keith Thompson

"v4vijayakumar" <v4***********@yahoo.com> writes:

Vladimir Oka wrote:
v4vijayakumar opined:
> Robert Gamble wrote:
>> muttaa wrote:

<snip>
>> > x=x++ + ++x;

<snip>
>> The behavior is undefined, x can now be any value. I would suggest
>> you read our FAQ at <http://c-faq.com/expr/index.html>, start with
>> question 3.2.
>
> why programming languages have undefined behavior?

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

<snip>

It seems that these are problems(?!) with 'sequence points'. When
operands (x++) could be potential expressions then why don't introduce
more 'sequence points'?! any performance issues?!

Introducing more sequence points and defining order of evaluation more
tightly would eliminate some, but not all, instances of undefined
behavior. It would also limit the kinds of optimization that
compilers can perform.

Many of the constructs that invoke undefined behavior are just plain
ugly anyway. Take a look at the example above:

x = x++ + ++x;

Why would you want to write such a thing in the first place? Whatever
it's supposed to do, there's certainly a cleaner way to express it.
On one system I just tried, it sets x to 2 * x + 3. If you want to do
that, just do it:

x = 2 * x + 3;

The rules are designed to allow good optimization (which will vary
from one system to another) while making carefully written code
well-defined.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

May 22 '06 #22

aone1504

We just tried the following expressions in MSVC one by one:-

with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

In (1) first ++x is evaluated to give 1. The second ++x is then
evaluated to give 2. Now the sum of 2 operands around + is 2 + 2 )

In (2) after ++x we get 1 next ++x gives 2; next ++x gives 3. But the
compiler keeps the result of first 2 operands separately ( ie., ++x +
++x = 4 ) and add 3 to give 7.

In (3) and (4) it works in the same way. The result of first 2 operands
is kept separately and then added to the result of the subseqent
operands.
Murli

Keith Thompson wrote:

"v4vijayakumar" <v4***********@yahoo.com> writes:
Vladimir Oka wrote:
v4vijayakumar opined:
> Robert Gamble wrote:
>> muttaa wrote:

<snip>

>> > x=x++ + ++x;

<snip>

>> The behavior is undefined, x can now be any value. I would suggest
>> you read our FAQ at <http://c-faq.com/expr/index.html>, start with
>> question 3.2.
>
> why programming languages have undefined behavior?

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

<snip>

It seems that these are problems(?!) with 'sequence points'. When
operands (x++) could be potential expressions then why don't introduce
more 'sequence points'?! any performance issues?!

Introducing more sequence points and defining order of evaluation more
tightly would eliminate some, but not all, instances of undefined
behavior. It would also limit the kinds of optimization that
compilers can perform.

Many of the constructs that invoke undefined behavior are just plain
ugly anyway. Take a look at the example above:

x = x++ + ++x;

Why would you want to write such a thing in the first place? Whatever
it's supposed to do, there's certainly a cleaner way to express it.
On one system I just tried, it sets x to 2 * x + 3. If you want to do
that, just do it:

x = 2 * x + 3;

The rules are designed to allow good optimization (which will vary
from one system to another) while making carefully written code
well-defined.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

May 22 '06 #23

aone1...@yahoo.com wrote:

Do not top post. Your reply belongs below and/or intersperesed with the
post you're replying to. I've fixed it here.

Also, don't quote signatures, unless you're commenting on them.

Keith Thompson wrote:
"v4vijayakumar" <v4***********@yahoo.com> writes:
Vladimir Oka wrote:
> v4vijayakumar opined:
> > Robert Gamble wrote:
> >> muttaa wrote:
>
> <snip>
>
> >> > x=x++ + ++x;
>
> <snip>
>
> >> The behavior is undefined, x can now be any value. I would suggest
> >> you read our FAQ at <http://c-faq.com/expr/index.html>, start with
> >> question 3.2.
> >
> > why programming languages have undefined behavior?
>
> Because it is not feasible to define behaviour of every possible
> language construct that the grammar allows -- especially the silly
> ones.

<snip>

It seems that these are problems(?!) with 'sequence points'. When
operands (x++) could be potential expressions then why don't introduce
more 'sequence points'?! any performance issues?!

Introducing more sequence points and defining order of evaluation more
tightly would eliminate some, but not all, instances of undefined
behavior. It would also limit the kinds of optimization that
compilers can perform.

Many of the constructs that invoke undefined behavior are just plain
ugly anyway. Take a look at the example above:

x = x++ + ++x;

Why would you want to write such a thing in the first place? Whatever
it's supposed to do, there's certainly a cleaner way to express it.
On one system I just tried, it sets x to 2 * x + 3. If you want to do
that, just do it:

x = 2 * x + 3;

The rules are designed to allow good optimization (which will vary
from one system to another) while making carefully written code
well-defined.

We just tried the following expressions in MSVC one by one:-

with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

In (1) first ++x is evaluated to give 1. The second ++x is then
evaluated to give 2. Now the sum of 2 operands around + is 2 + 2 )

In (2) after ++x we get 1 next ++x gives 2; next ++x gives 3. But the
compiler keeps the result of first 2 operands separately ( ie., ++x +
++x = 4 ) and add 3 to give 7.

In (3) and (4) it works in the same way. The result of first 2 operands
is kept separately and then added to the result of the subseqent
operands.

Your efforts are a complete and utter waste of time. Since all of the
expressions above invoke Undefined Behaviour, the fact that you got the
results you quote is totally irrelevant. Next time you try your head
may turn to a turnip, or you may observe some pigs performing some
aerobatic manouvers.

Don't waste your time or Usenet bandwith. Just don't do these things.

May 22 '06 #24

ao******@yahoo.com wrote:

We just tried the following expressions in MSVC one by one:-

with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

In (1) first ++x is evaluated to give 1. The second ++x is then
evaluated to give 2. Now the sum of 2 operands around + is 2 + 2 )

In (2) after ++x we get 1 next ++x gives 2; next ++x gives 3. But the
compiler keeps the result of first 2 operands separately ( ie., ++x +
++x = 4 ) and add 3 to give 7.

In (3) and (4) it works in the same way. The result of first 2 operands
is kept separately and then added to the result of the subseqent
operands.
Murli

<snip>

You mean, predictable undefined behavior! :)

May 22 '06 #25

pete

ao******@yahoo.com wrote:

We just tried the following expressions in MSVC one by one:-

with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

In (1) first ++x is evaluated to give 1. The second ++x is then
evaluated to give 2. Now the sum of 2 operands around + is 2 + 2 )

In (2) after ++x we get 1 next ++x gives 2; next ++x gives 3. But the
compiler keeps the result of first 2 operands separately ( ie., ++x +
++x = 4 ) and add 3 to give 7.

In (3) and (4) it works in the same way.
The result of first 2 operands
is kept separately and then added to the result of the subseqent
operands.

That's all about your compiler,
and not at all about the rules of C.

--
pete

May 22 '06 #26

John Bode

v4vijayakumar wrote:

ao******@yahoo.com wrote:
We just tried the following expressions in MSVC one by one:-

with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

In (1) first ++x is evaluated to give 1. The second ++x is then
evaluated to give 2. Now the sum of 2 operands around + is 2 + 2 )

In (2) after ++x we get 1 next ++x gives 2; next ++x gives 3. But the
compiler keeps the result of first 2 operands separately ( ie., ++x +
++x = 4 ) and add 3 to give 7.

In (3) and (4) it works in the same way. The result of first 2 operands
is kept separately and then added to the result of the subseqent
operands.
Murli

<snip>

You mean, predictable undefined behavior! :)

It's predictable until you compile the code on a different platform.
Or on the same platform with a different compiler. Or the same
platform and compiler with different optimization settings. Or the
same platform, compiler, and optimization settings, but with a
different order of operations.

The behavior is undefined. Individual compilers will do *something*
with the expression, and that *something* will probably be consistent
for a given context, but writing code to anticipate or exploit that
behavior is usually a mistake.

For giggles, I went through all the possible permutations of x++ + x++,
x++ + ++ x, etc., using both VS for Windows and MPW for MacOS, and on
each platform at least one of the permutations gave a "wrong" result,
and the permutations that gave "wrong" results were different between
the two platforms.

May 22 '06 #27

Al Balmer

On 22 May 2006 06:43:20 -0700, ao******@yahoo.com wrote:

We just tried the following expressions in MSVC one by one:-

Who cares? Now, tell me the results for the three compilers I use the
most.

--
Al Balmer
Sun City, AZ

May 22 '06 #28

Kenneth Brody

Vladimir Oka wrote:

v4vijayakumar opined:

[...]

> x=x++ + ++x;
[...] why programming languages have undefined behavior?

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

Not to mention that forcing a certain behavior for such silly constructs
would impose an unnecessary burden on the compiler writer by preventing
the compiler from generating code which takes advantage of certain
hardware. (For example, a CPU which includes a "load an increment"
operator.) Or by eliminating the ability to optimize code by forcing
the statement to be evaluated in a specific order.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

May 22 '06 #29

Richard Tobin

In article <bs********************@bt.com>,
Vladimir Oka <no****@btopenworld.com> wrote:

why programming languages have undefined behavior?
Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

It's quite feasible, it's just not a choice that C made. For example,
it could be defined that all pointers are checked and an error occurs
if you dereference a bogus one. But this would be against the spirit
of C in two ways: it would impose an overhead on correct code, and it
would prevent C being used for straightforward manipulation of
arbitrary memory locations, for example in device drivers.

The C standard is not designed with the expectation that all programs
are conforming; it guarantees the behaviour of conforming programs and
allows other standards to extend it while still letting C be used as
"a better assembler".

-- Richard

May 22 '06 #30

Dik T. Winter

In article <e4**********@pc-news.cogsci.ed.ac.uk> ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <bs********************@bt.com>,
Vladimir Oka <no****@btopenworld.com> wrote:
why programming languages have undefined behavior?

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

It's quite feasible, it's just not a choice that C made.

Indeed. In a language like Algol 60 *each* construct had a precisely
defined meaning, even the silly ones.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

May 23 '06 #31

CBFalconer

ao******@yahoo.com wrote:

We just tried the following expressions in MSVC one by one:-
with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

No it doesn't. As has been explained elsewhere, the behaviour is
undefined, and you are doing nothing but ill in suggesting
otherwise.

In addition, you are top-posting, which is not acceptable. Your
answers belong after (or intermixed with) the *snipped* material to
which you reply. Snip anything that is not germane to your reply.

--
"If you want to post a followup via groups.google.com, 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
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

May 23 '06 #32

Ben Pfaff

"Dik T. Winter" <Di********@cwi.nl> writes:

In article <e4**********@pc-news.cogsci.ed.ac.uk> ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
> In article <bs********************@bt.com>,
> Vladimir Oka <no****@btopenworld.com> wrote:
>
> >> why programming languages have undefined behavior?

>
> >Because it is not feasible to define behaviour of every possible
> >language construct that the grammar allows -- especially the silly
> >ones.

>
> It's quite feasible, it's just not a choice that C made.

Indeed. In a language like Algol 60 *each* construct had a precisely
defined meaning, even the silly ones.

Java is a more modern example, as I understand it.
--
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield

May 23 '06 #33

aone1504

This is a behavior observed in MSVC and this is predictable. The
compiler is going to give me the same result whenever I execute this
code. This is predictable. What do you mean by undefined when I am able
to define it. Do not write such irresponsible mails based on your
limitations and based on loose statements like "undefined". I do not
care what is undefined as long as it works the way it is expected to
for a specific compiler. I encourage people to investigate this
behavior further and disseminate and find applications for such
expressions. I reiterate pls. do not write such replies.

Rgds.

May 23 '06 #34

ao******@yahoo.com wrote:

This is a behavior observed in MSVC and this is predictable. The
compiler is going to give me the same result whenever I execute this
code. This is predictable. What do you mean by undefined when I am able
to define it. Do not write such irresponsible mails based on your
limitations and based on loose statements like "undefined". I do not
care what is undefined as long as it works the way it is expected to
for a specific compiler. I encourage people to investigate this
behavior further and disseminate and find applications for such
expressions. I reiterate pls. do not write such replies.

Rgds.

cool. don't be emotional, just be rational.

It may work with your compiler but what if you change your compiler.
Propably, it may fail to work the way you thought. C language
specification says that result of such statements (x = x++ + ++x) are
"undefined" and it is not opinion of the people who posted it.

It seems that you are directly replying from google groups. Don't use
reply link but use reply link in 'show options'. and, learn to quote.
go through the following links,
http://en.wikipedia.org/wiki/Nettiquette
http://en.wikipedia.org/wiki/Top-posting

All the best!

May 23 '06 #35

Gordon Burditt

> This is a behavior observed in MSVC and this is predictable. The

Have you tried it with all versions of MSVC at all optimization
levels? Have you tried it on the NEXT version of MSVC? Does
Microsoft documentation guarantee that the code will continue
to work the same way?

compiler is going to give me the same result whenever I execute this
code.
If you're only going to execute this code with MSVC, why not
post it only to a group for MSVC?
This is predictable. What do you mean by undefined when I am able
to define it.
The definition of "undefined behavior" is fairly clear in the C
language standard, which you do not get to re-write (and for that
matter, neither does Microsoft. And although Microsoft does like
non-standard extensions a lot, their compilers seem to follow the
standard about as well as other compiler writers.)
Do not write such irresponsible mails based on your
limitations and based on loose statements like "undefined".
The definition of "undefined behavior" in the C standard is not
loose at all. Criticizing code for containing undefined behavior
is not "irresponsible".
I do not
care what is undefined as long as it works the way it is expected to
for a specific compiler.
You're never going to upgrade your MSVC to a newer version?
Not even when it quits working on Windows 2014XL?
I encourage people to investigate this
behavior further and disseminate and find applications for such
expressions. I reiterate pls. do not write such replies.

Please do not write such code. Or if you must, please do not
release it to anyone unless they have paid you a ridiculous
amount of money for it, and especially do not post it or give
it away free.

Gordon L. Burditt

May 23 '06 #36

Robert Latest

On 22 May 2006 23:42:31 -0700,
ao******@yahoo.com <ao******@yahoo.com> wrote
in Msg. <11**********************@j33g2000cwa.googlegroups .com>

What do you mean by undefined when I am able
to define it.
In this newsgroup, the C Standard says what is defined and what is not.
Furthermore, to say that you can define something by observing a few
instances of a certain behavior of a system (any system, not just a C
compiler) is just plain loony. Heuristics is, by definition, not a
definition
Do not write such irresponsible mails based on your
limitations and based on loose statements like "undefined".
"Undefined" has, in the context of the C language, a very precisely
defined meaning. Look at the clc FAQ.
I do not care what is undefined as long as it works the way it is
expected to for a specific compiler.
You're welcome to that.
I encourage people to investigate this behavior further and
disseminate and find applications for such expressions.
Fortunately you don't.
I reiterate pls. do not write such replies.

Not only will people continue to write "such" replies, but they will
enjoy using a progressively sharper tone.

robert

May 23 '06 #37

Flash Gordon

v4vijayakumar wrote:

ao******@yahoo.com wrote:
This is a behavior observed in MSVC and this is predictable. The
compiler is going to give me the same result whenever I execute this
code. This is predictable. What do you mean by undefined when I am able
to define it. Do not write such irresponsible mails based on your
limitations and based on loose statements like "undefined". I do not
care what is undefined as long as it works the way it is expected to
for a specific compiler. I encourage people to investigate this
behavior further and disseminate and find applications for such
expressions. I reiterate pls. do not write such replies.

Rgds.
cool. don't be emotional, just be rational.

It may work with your compiler but what if you change your compiler.

Or MS release a patch which changes the behaviour, something they are
quite entitled to do. Or you add a line before or after which makes the
compiler decide to optimise it differently. Or...
Propably, it may fail to work the way you thought. C language
specification says that result of such statements (x = x++ + ++x) are
"undefined" and it is not opinion of the people who posted it.
Correct.
It seems that you are directly replying from google groups. Don't use
reply link but use reply link in 'show options'. and, learn to quote.
go through the following links,
http://en.wikipedia.org/wiki/Nettiquette
http://en.wikipedia.org/wiki/Top-posting

Also http://clc-wiki.net/wiki/Intro_to_clc and the Google specific
section there in.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

May 23 '06 #38

aone1504

Thanks for your response. I am fully aware of the problems associated
with using such constructs. What I am trying to say is that, if we can
find out useful applications for expressions such as these, then it
makes sense for compiler writer to include this as a part of the
definition. Of course, there would still be many expressions which are
left out by compiler writers, but then a useful extension has been
made. The purpose of writing this is to arrive at some useful
extensions which would be of help to programmers rather than shutting
the door based on the current definition of the language.

Thanks so much.
Gordon Burditt wrote:

This is a behavior observed in MSVC and this is predictable. The

Have you tried it with all versions of MSVC at all optimization
levels? Have you tried it on the NEXT version of MSVC? Does
Microsoft documentation guarantee that the code will continue
to work the same way?
compiler is going to give me the same result whenever I execute this
code.

If you're only going to execute this code with MSVC, why not
post it only to a group for MSVC?
This is predictable. What do you mean by undefined when I am able
to define it.

The definition of "undefined behavior" is fairly clear in the C
language standard, which you do not get to re-write (and for that
matter, neither does Microsoft. And although Microsoft does like
non-standard extensions a lot, their compilers seem to follow the
standard about as well as other compiler writers.)
Do not write such irresponsible mails based on your
limitations and based on loose statements like "undefined".

The definition of "undefined behavior" in the C standard is not
loose at all. Criticizing code for containing undefined behavior
is not "irresponsible".
I do not
care what is undefined as long as it works the way it is expected to
for a specific compiler.

You're never going to upgrade your MSVC to a newer version?
Not even when it quits working on Windows 2014XL?
I encourage people to investigate this
behavior further and disseminate and find applications for such
expressions. I reiterate pls. do not write such replies.

Please do not write such code. Or if you must, please do not
release it to anyone unless they have paid you a ridiculous
amount of money for it, and especially do not post it or give
it away free.

Gordon L. Burditt

May 23 '06 #39

pete

ao******@yahoo.com wrote:

Thanks for your response. I am fully aware of the problems associated
with using such constructs.
Really?
I ask because
"What do you mean by undefined when I am able to define it."
is the kind of thing
that somebody who had absolutely no idea
of what the concept of "undefined behavior" was,
might say.

What I am trying to say is that, if we can
find out useful applications for expressions such as these, then it
makes sense for compiler writer to include this as a part of the
definition. Of course, there would still be many expressions which are
left out by compiler writers, but then a useful extension has been
made. The purpose of writing this is to arrive at some useful
extensions which would be of help to programmers rather than shutting
the door based on the current definition of the language.

That's bad.
By contrast, what is good, is to know the difference between
code with "undefined behavior" and "correct code".

The fact that
x= ++x + ++x gives 4
on your C implementation, isn't worth knowing to a C programmer.

The fact that
x= ++x + ++x
is undefined, because of the rules of C,
which say that an attempt to modify an object more than once
between two sequence points is undefined, is worth knowing.
That's part of knowing C.
If you don't know that, then you don't know C.

The topic of this newsgroup is C.

You can read one of the documents at this URL to get
some idea of what C is:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n869/
That's the last public draft of the standard,
it's mostly accurate, but not entirely.

You can read the document at this URL to get
some idea of what C is going to be:
http://www.open-std.org/JTC1/SC22/WG...docs/n1124.pdf
That's a public draft of the next standard.

--
pete

May 23 '06 #40

Robert Latest

On 23 May 2006 01:25:28 -0700,
ao******@yahoo.com <ao******@yahoo.com> wrote
in Msg. <11********************@i40g2000cwc.googlegroups.c om>

The purpose of writing this is to arrive at some useful
extensions which would be of help to programmers rather than shutting
the door based on the current definition of the language.
OK. Compiler extension. Good. Many compiler extensions exist for many
compilers, many of them exist for good reasons. They are used
frequently, and some even made it into the current C Standard.

A common reason for an extension to exist is that it is useful. Show us
something useful.
Thanks so much.

No. /We/ have to thank /you/ for your suggestions. I sometimes find it
quite enlightening how a complete newbie can shine some fresh light on
an old subject and really open up new directions in which the C language
could evolve in the future.

robert

May 23 '06 #41

Nick Keighley

Dik T. Winter wrote:

In article <e4**********@pc-news.cogsci.ed.ac.uk> ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
> In article <bs********************@bt.com>,
> Vladimir Oka <no****@btopenworld.com> wrote:
> >> why programming languages have undefined behavior?

>
> >Because it is not feasible to define behaviour of every possible
> >language construct that the grammar allows -- especially the silly
> >ones.

>
> It's quite feasible, it's just not a choice that C made.

Indeed. In a language like Algol 60 *each* construct had a precisely
defined meaning, even the silly ones.

I thought even Alogol-60 had holes in its semantics? Wasn't
call-by-name with
nested functions a bit hairy? This is based on a very vague memory...
--
Nick Keighley

May 23 '06 #42

Richard Tobin wrote:

In article <bs********************@bt.com>,
Vladimir Oka <no****@btopenworld.com> wrote:
why programming languages have undefined behavior?
Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

It's quite feasible, it's just not a choice that C made.

<snip>
The C standard is not designed with the expectation that all programs
are conforming; it guarantees the behaviour of conforming programs and
allows other standards to extend it while still letting C be used as
"a better assembler".

Quite so. It was a bad choice of word on my part.

May 23 '06 #43

Dik T. Winter

In article <11**********************@j55g2000cwa.googlegroups .com> "Nick Keighley" <ni******************@hotmail.com> writes:

Dik T. Winter wrote:
In article <e4**********@pc-news.cogsci.ed.ac.uk> ri*****@cogsci.ed.ac.uk (Richard Tobin) writes: ....
> It's quite feasible, it's just not a choice that C made.

Indeed. In a language like Algol 60 *each* construct had a precisely
defined meaning, even the silly ones.

I thought even Alogol-60 had holes in its semantics? Wasn't
call-by-name with
nested functions a bit hairy? This is based on a very vague memory...

It was hairy, but well-defined. The problem was that it was a side-effect
of a strict definition that was not foreseen (and that some people at that
time thought not implementable).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

May 23 '06 #44

CBFalconer said:

ao******@yahoo.com wrote:

We just tried the following expressions in MSVC one by one:-
with initial value of x = 0;

(1) :- x= ++x + ++x gives 4 ( ie., 2 + 2 )
(2) :- x= ++x + ++x + ++x gives 7 ( ie., 2 + 2 + 3 )
(3) :- x = ++x + ++x + ++x + ++x gives 11 ( ie., 2 + 2 + 3 + 4 )
(4) :- x = ++x + ++x + ++x + ++x + ++x gives 16 ( ie., 2 + 2 + 3 +
4 + 5 )

It appears to work like this:-

No it doesn't.

Er, yes, it does. That is, it does *appear* to work like this. The problem
here is that appearance and reality are not always the same thing. The
reality is that the behaviour is undefined, but the /appearance/ is that it
is reproducible. To dispel the appearance would require access to
implementations other than the one being used by the OP, and a willingness
to learn from those implementations and from the wording of the Standard.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

May 23 '06 #45

Richard Tobin said:

In article <bs********************@bt.com>,
Vladimir Oka <no****@btopenworld.com> wrote:
why programming languages have undefined behavior?

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

It's quite feasible, it's just not a choice that C made.

To define every possible behaviour, a programming language would have to be
a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent. That is, there will be some behaviours
that cannot be defined. And if it is not a sufficiently powerful formal
system, it loses interest.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

May 23 '06 #46

pete

Richard Heathfield wrote:

Richard Tobin said:
In article <bs********************@bt.com>,
Vladimir Oka <no****@btopenworld.com> wrote:
why programming languages have undefined behavior?

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

It's quite feasible, it's just not a choice that C made.

To define every possible behaviour,
a programming language would have to be
a formal system. If it is a sufficiently powerful formal system,
it is either incomplete or inconsistent.
That is, there will be some behaviours
that cannot be defined.
And if it is not a sufficiently powerful formal
system, it loses interest.

C is a much simpler language with undefined behavior
than it would be without it.

I can fully evaluate these four expressions at a glance:

(1) :- x= ++x + ++x
(2) :- x= ++x + ++x + ++x
(3) :- x = ++x + ++x + ++x + ++x
(4) :- x = ++x + ++x + ++x + ++x + ++x

They're all undefined.

--
pete

May 23 '06 #47

Chris Dollin

Richard Heathfield wrote:

Richard Tobin said:
In article <bs********************@bt.com>,
Vladimir Oka <no****@btopenworld.com> wrote:
why programming languages have undefined behavior?
Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

It's quite feasible, it's just not a choice that C made.

To define every possible behaviour, a programming language would have to be
a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent.

Um ... I don't think that applies in the Goedel sense; (imperative) programs
represent functions (from states to states, roughly), they can't be
inconsistent, any more than a brick or oxygen can.
That is, there will be some behaviours that cannot be defined.
That's true. Some things are uncomputable.

(And some are too expensive, and others are too complicated to write
reliably in Current Preferred Language.)
And if it is not a sufficiently powerful formal
system, it loses interest.

Adding undefined behaviour, C-style, doesn't change that. Unless, I
suppose, the demon that flies out of your nose is also clutching the
answer to your question ...

--
Chris "Maxwell" Dollin
"Who do you serve, and who do you trust?" /Crusade/

May 23 '06 #48