++ devils

[Vladimir Oka]

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

 

[Keith Thompson]

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

 

[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

 

[Vladimir Oka]

(e-mail address removed) 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.

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.

 

[v4vijayakumar]

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!

 

[pete]

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.

 

[John Bode]

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

 

[Al Balmer]

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.

 

[Kenneth Brody]

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:[email protected]>

 

[CBFalconer]

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/>

 

[Richard Tobin]

why programming languages have undefined behavior?

[/QUOTE]

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

 

[Dik T. Winter]

> In article <[email protected]>,

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

 

[Ben Pfaff]

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.

 

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

 

[v4vijayakumar]

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!

 

[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

 

[Flash Gordon]

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.

 

[Robert Latest]

On 22 May 2006 23:42:31 -0700,

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

 

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

 

[pete]

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/WG14/www/docs/n1124.pdf
That's a public draft of the next standard.