Need experts suggestion

[Dietmar Schindler]

C99
4. Conformance
...
2 If a ‘‘shall’’ or ‘‘shall not’’ requirement
that appears outside of a constraint is violated,
the behavior is undefined.
Undefined behavior is otherwise indicated in this International
Standard by the words ‘‘undefined behavior’’
or by the omission of any explicit definition of behavior.
There is no difference in emphasis among these three;
they all describe ‘‘behavior that is undefined’’.

I can only refer to n1124, but I think you seriously misquoted the last
clause. It reads there:

they all describe "behavior that is undefined".

The quotation marks make a crucial difference. Without them, the verb
'describe' relates to 'behavior', and that behavior be undefined. This
is nonsense: behavior which is described is not undefined. With the
correct quotation, the verb 'describe' relates to the phrase 'behavior
that is undefined’’'. Thus, there is no description of behavior, but
merely a description of that phrase.

Failure to differentiate between these often leads to ridiculous
statements like "code invokes undefined behavior". Behavior which is
invoked is defined *de facto* by the result of its very invocation. It
would be acceptable to say "code has undefined behavior", which just
means "the behavior of the code is not defined by the International
Standard".

Undefined behavior, by the way, does also not mean "anything can
happen". Even if the International Standard does not forbid a certain
event, there are still other authorities, such as the laws of physics. I
get a headache every time I read about those (in)famous 'nasal demons'.
Yet, one might say that this headache is caused just by those demons
waiting to fly out of my nose.

 

[Malcolm]

It
would be acceptable to say "code has undefined behavior", which just
means "the behavior of the code is not defined by the International
Standard".

Exactly. Implementations can and do define a null pointer dereference to
print out a message such as "segmentation fault".

Undefined behavior, by the way, does also not mean "anything can
happen". Even if the International Standard does not forbid a certain
event, there are still other authorities, such as the laws of physics. I
get a headache every time I read about those (in)famous 'nasal demons'.
Yet, one might say that this headache is caused just by those demons
waiting to fly out of my nose.

This is what I all the Shakespearian monkey fallacy. It claims that if you
have a sufficiently large number of monkeys with typewriters, you will
eventually produce the works of Shakespeare.
Humans who buy lottery tickets with million dollar headline prizes are
committing the same fallacy. We are simply not wired to believe that random
events do not produce humanly-meaningful results more often than chance. In
particular, corrupting a computer's memory with random garbage is extremely
unlikely to produce anything other than a crash, not nasal demons or little
elves on screen.

 

[pete]

pete wrote:

they all describe "behavior that is undefined".

The quotation marks make a crucial difference.

That's the way my copy and paste, works with pdf files.

 

[Keith Thompson]

Exactly. Implementations can and do define a null pointer dereference to
print out a message such as "segmentation fault".

Sure, but attempting to dereference a pointer with a garbage value
won't necessarily cause a segmentation fault. It might just happen to
point to valid data (just not the data it's supposed to point to).

This is what I all the Shakespearian monkey fallacy. It claims that if you
have a sufficiently large number of monkeys with typewriters, you will
eventually produce the works of Shakespeare.
Humans who buy lottery tickets with million dollar headline prizes are
committing the same fallacy. We are simply not wired to believe that random
events do not produce humanly-meaningful results more often than chance. In
particular, corrupting a computer's memory with random garbage is extremely
unlikely to produce anything other than a crash, not nasal demons or little
elves on screen.

Events that cause undefined behavior are seldom truly random. If
software runs in a *malicious* environment, a coding error that causes
undefined behavior will very likely be exploited to cause results far
worse than a simple crash (worms, viruses, etc.).

Some time ago, my laptop's hard drive failed badly enough that it had
to be replaced. I don't know what caused it, but it's entirely
possible that it was the result of undefined behavior in some piece of
C code.

And some people do win millions of dollars in lotteries.

 

[Eric Sosman]

[...]
Undefined behavior, by the way, does also not mean "anything can
happen". Even if the International Standard does not forbid a certain
event, there are still other authorities, such as the laws of physics. I
get a headache every time I read about those (in)famous 'nasal demons'.
Yet, one might say that this headache is caused just by those demons
waiting to fly out of my nose.

"Anything can happen" is, as you point out, something of
an overstatement. Perhaps "Nothing is forbidden to happen"
might be a better way of describing undefined behavior.

As for the demons: Once upon a time when the ANSI Standard
was new, posters to comp.lang.c took some delight in coming up
with inventive and amusing descriptions of "unforbidden" behavior.
They began with (relatively) plausible things like "Dereferencing
a null pointer will burn a hole in your monitor" (a reference to
something that, I'm told, could actually happen with some early
PCs), or "fflush(stdin) will reformat your hard drive." It
didn't take long for the descriptions to become more fanciful:
"Shift by a negative bit count and chocolate pudding will ooze
from your floppy drive" or "Try to reference free()d memory and
your computer's too too solid silicon will melt, thaw, and resolve
itself into a dew."

Eventually (and quite suddenly, for some reason), "Demons
will fly out of your nose" became the canonical description of
all undefined behavior. There's nothing particularly special
about these demons, except that they seem to have put an abrupt
end to the same stream of whimsical inventiveness that engendered
them. If they give you headaches, perhaps you can obtain relief
by reopening the long-shuttered windows of creativity and letting
some other U.B. descriptions take to the air for a while.

It'd be more fun to read amusing U.B. descriptions than to
read endless broadsides against Googlers.

 

[Al Balmer]

This is what I all the Shakespearian monkey fallacy.

Oh? I always called it a joke.

I *really* don't think that users of the phrase mean it to be taken
literally.

 

[Malcolm]

Oh? I always called it a joke.

I *really* don't think that users of the phrase mean it to be taken
literally.

One of the characteristics of an identified fallacy is that there is some
group of people somewhere who do not fall prey to it.

How many people do you know who buy lottery tickets?
In the British National Lottery, the chance of getting the winning
combination is 14 million to one, and the jackpot not infrequently is over
14 million. Why do you think I still don't buy a ticket on these occasions?

 

[CBFalconer]

.... snip ...


Oh? I always called it a joke.

I *really* don't think that users of the phrase mean it to be taken
literally.

We have told you at least a billion times, always exagerate the
effects of UB.

BTW, you snipped the attributions of quoted material. Please don't.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Al Balmer]

We have told you at least a billion times, always exagerate the
effects of UB.

BTW, you snipped the attributions of quoted material. Please don't.

Apologies to Dietmar. I shouldn't be allowed on a computer after 10PM.

 

[Jordan Abel]

One of the characteristics of an identified fallacy is that there
is some group of people somewhere who do not fall prey to it.

How many people do you know who buy lottery tickets?
In the British National Lottery, the chance of getting the winning
combination is 14 million to one, and the jackpot not infrequently
is over 14 million. Why do you think I still don't buy a ticket on
these occasions?

Because more people will buy tickets in those cases, increasing the
odds of multiple winners (cutting your winnings in half or worse)

 

[CBFalconer]

.... snip ...

How many people do you know who buy lottery tickets?
In the British National Lottery, the chance of getting the winning
combination is 14 million to one, and the jackpot not infrequently
is over 14 million. Why do you think I still don't buy a ticket on
these occasions?

Because (one or more of) those aren't really the odds because they
use an extended payoff, and you have to pay taxes on the winnings,
again changing the odds.

I limit my betting to things with a positive expectation. Give me
a 5% edge and I will be quite active.

--
"Our enemies are innovative and resourceful, and so are we.
They never stop thinking about new ways to harm our country
and our people, and neither do we." -- G. W. Bush.
"The people can always be brought to the bidding of the
leaders. All you have to do is tell them they are being
attacked and denounce the pacifists for lack of patriotism
and exposing the country to danger. It works the same way
in any country." --Hermann Goering.

 

[Richard Tobin]

How many people do you know who buy lottery tickets?
In the British National Lottery, the chance of getting the winning
combination is 14 million to one, and the jackpot not infrequently
is over 14 million. Why do you think I still don't buy a ticket on
these occasions?

[/QUOTE]

Because more people will buy tickets in those cases, increasing the
odds of multiple winners (cutting your winnings in half or worse)

Even if this were not so, the figures merely mean that your expected
gain is positive. I am interested in maximising my actual gain, not
my expected gain.

-- Richard

 

[Jordan Abel]

Because more people will buy tickets in those cases, increasing the
odds of multiple winners (cutting your winnings in half or worse)

Even if this were not so, the figures merely mean that your expected
gain is positive. I am interested in maximising my actual gain, not
my expected gain.[/QUOTE]

The only way to maximize your actual gain is to win. Since this is out
of your control, the next best thing is to maximize your expected gain.

 

[Richard Tobin]

The only way to maximize your actual gain is to win. Since this is out
of your control, the next best thing is to maximize your expected gain.

No, this it not true. Most people will maximise their actual gain by
never entering a lottery, even when the expectation is positive.

The (strong and weak) laws of large numbers are theorems relating
expected gain to actual gain, and show that if certain facts are true
of the distribution of results then your actual gain will almost
certainly tend to the expectation. But these laws do not apply to
lotteries of the kind under discussion, since the number of trials
available is nowhere near large enough.

-- Richard

 

[Jordan Abel]

No, this it not true. Most people will maximise their actual gain by
never entering a lottery, even when the expectation is positive.

The (strong and weak) laws of large numbers are theorems relating
expected gain to actual gain, and show that if certain facts are true
of the distribution of results then your actual gain will almost
certainly tend to the expectation. But these laws do not apply to
lotteries of the kind under discussion, since the number of trials
available is nowhere near large enough.

Then they're using a different definition of "expected" than I learned,
and your probabilistic "actual gain" corresponds _exactly_ to what
I learned the term "expected value" to describe.

 

[Mark F. Haigh]

Dietmar Schindler wrote:

Undefined behavior, by the way, does also not mean "anything can
happen". Even if the International Standard does not forbid a certain
event, there are still other authorities, such as the laws of physics. I
get a headache every time I read about those (in)famous 'nasal demons'.
Yet, one might say that this headache is caused just by those demons
waiting to fly out of my nose.

You're mistaken. I don't see the so-called "laws of physics" amongst
the C99 normative references.

And don't try to blame your hangover on the nasal demons. They
_really_ don't like that.


Mark F. Haigh
(e-mail address removed)

 

[Guest]

Dietmar Schindler wrote:


You're mistaken. I don't see the so-called "laws of physics" amongst
the C99 normative references.

And don't try to blame your hangover on the nasal demons. They
_really_ don't like that.

So, if a compiler can prove that a given statement will always be
reached, and that it will always have UB, there is no requirement that
anything up to that statement must be executed, even if "anything up to
that statement" includes for example, printer output, or anything else
that cannot possibly be undone in reality?

 

[Eric Sosman]

So, if a compiler can prove that a given statement will always be
reached, and that it will always have UB, there is no requirement that
anything up to that statement must be executed, even if "anything up to
that statement" includes for example, printer output, or anything else
that cannot possibly be undone in reality?

It's debatable, but I think that's correct. For
example, consider

#include <stdio.h>
int main(void) {
printf ("Hello, world!\n");
/* No U.B. prior to this point */
return 1 / 0;
}

If the compiler tries to replace `1 / 0' by a constant
value computed at compile time and while doing so detects the
division by zero, I believe it is within its rights to refuse
to accept the program. If it refuses the program, the program
will not run and will not produce output, so the division by
zero effectively cancels "earlier" side-effects.

 

[Mark F. Haigh]

So, if a compiler can prove that a given statement will always be
reached, and that it will always have UB, there is no requirement that
anything up to that statement must be executed, even if "anything up to
that statement" includes for example, printer output, or anything else
that cannot possibly be undone in reality?

Precisely. In fact, Chris Torek used to work on several machines that
would "bend" their endianness and/or NULL pointer bit values according
to the lesson they were trying to teach you.

Rough times, they were.

Mark F. Haigh
(e-mail address removed)

 

[Mark F. Haigh]

Lets say we've got a non-trivial problem, such as writing a C compiler.
There are methods you can go through to try to produce a correct program. We
can't surrender the word "correct" to a committee that can't even come up
with a usable standard. Many correct C compilers are in fact written.
However to actually prove that the compiler will work correctly on all input
is a very difficult thing to do. There are in fact no official test suites,
because no one has managed to devise one that ensures compliance.

There's never going to be a test that if passed, ensures C compliance,
simply because it would be infinite. The best compliance tests are the
ones that test many subtly different _classes_ of problems, rather than
spending time on testing whether 64 bit addition works for all possible
values of x and y.


Mark F. Haigh
(e-mail address removed)