hi,
I found an interesting thing in operator behaviour in C++ :
int i=1;
printf("%d",i++ + i++);
I think the value of the expression "i++ + i++" _must_ be 3, but all the
compilers I tested print 2.
Then I tried another example
std::vector<int> a;
a.push_back(1);
a.push_back(2);
std::vector<int>::iterator i = a.begin();
printf("%d",*i++ + *i++);
Different compilers print different values : 2 or 3, thought it _must_ be 3.
Possibly, it is because of the compilers C compatibility, since iterators
are C++ construction and their behaviour therefore suits C++ standards,
while for the basic types compilers guarantee C behaviour.
Bjarne Stroustrup wrote in his book that
y = ++x; is equivalent to y = (x+=1);
while
y = x++; is equivalent to y = (t=x,x+=1,t);
Why do all the compilers incorrectly compute the expressions?
Many thanks in advance,
Dmitriy Iassenev.
36  3381 
On Thu, 2 Oct 2003 19:55:37 +0300, "Dmitriy Iassenev"
<ia******@gsc-game.kiev.ua> wrote: hi,
I found an interesting thing in operator behaviour in C++ :
int i=1;
printf("%d",i++ + i++);
I think the value of the expression "i++ + i++" _must_ be 3, but all the
compilers I tested print 2.
This is an FAQ: http://www.eskimo.com/~scs/C-faq/s3.html
Tom
Dmitriy Iassenev wrote: hi,
I found an interesting thing in operator behaviour in C++ :
int i=1;
printf("%d",i++ + i++);
I think the value of the expression "i++ + i++" _must_ be 3, but all
the compilers I tested print 2.
You think wrong. The above is undefined behavior. You try to change the
value of a variable more than once with an intervening sequence point. The
compiler is allowed to do whatever it wants, including formatting your
harddisk. Search for sequence point i+++++i on Google. One page is: http://www.embedded.com/story/OEG20020625S0041
--
WW aka Attila
int i=1;
printf("%d",i++ + i++);
I think the value of the expression "i++ + i++" _must_ be 3, but all the
compilers I tested print 2.
Bjarne Stroustrup wrote in his book that
y = ++x; is equivalent to y = (x+=1);
while
y = x++; is equivalent to y = (t=x,x+=1,t);
Why do all the compilers incorrectly compute the expressions?
His statement agrees with your test perfectly, doesn't it? You get back 2,
which is 1+1, and after that value is computed, then i gets incremented
(twice). Using his notation,
y = x++ + x++; would be like
y = (t = x+x, x+=1, x+= 1, t);
Right?
-Howard You think wrong. The above is undefined behavior. You try to change the
value of a variable more than once with an intervening sequence point.
The compiler is allowed to do whatever it wants, including formatting your
harddisk. Search for sequence point i+++++i on Google. One page is:
Oh, good point. I forgot about sequence points.
But regardless of what "undefined behavior" means in the standard, you had
best not sell me a compiler that formats my hard drive if I screw up simple
code like this...I know a good lawyer! :-)
-Howard
"Howard" <al*****@hotmail.com> wrote in message
news:bl********@dispatch.concentric.net...
int i=1;
printf("%d",i++ + i++);
I think the value of the expression "i++ + i++" _must_ be 3, but all the
compilers I tested print 2.
Bjarne Stroustrup wrote in his book that
y = ++x; is equivalent to y = (x+=1);
while
y = x++; is equivalent to y = (t=x,x+=1,t);
Why do all the compilers incorrectly compute the expressions?
His statement agrees with your test perfectly, doesn't it? You get back
2, which is 1+1, and after that value is computed, then i gets incremented
(twice). Using his notation,
y = x++ + x++; would be like
y = (t = x+x, x+=1, x+= 1, t);
Right?
Wrong. modifying the same variable twice in the same expression in
undefined so anything could happen.
"Dmitriy Iassenev" <ia******@gsc-game.kiev.ua> wrote in message
news:bl**********@news.lucky.net... hi,
I found an interesting thing in operator behaviour in C++ :
int i=1;
printf("%d",i++ + i++); http://www.eskimo.com/~scs/C-faq/q3.3.html
"Howard" <al*****@hotmail.com> wrote...
int i=1;
printf("%d",i++ + i++);
I think the value of the expression "i++ + i++" _must_ be 3, but all the
compilers I tested print 2.
Bjarne Stroustrup wrote in his book that
y = ++x; is equivalent to y = (x+=1);
while
y = x++; is equivalent to y = (t=x,x+=1,t);
Why do all the compilers incorrectly compute the expressions?
His statement agrees with your test perfectly, doesn't it? You get back
2, which is 1+1, and after that value is computed, then i gets incremented
(twice). Using his notation,
y = x++ + x++; would be like
y = (t = x+x, x+=1, x+= 1, t);
Right?
Nope. Modifying a value of an object twice between sequence points
causes undefined behaviour. Anything is allowed to happen.
The expression (x++ + x++) is NOT like (t = x+x, x+=2) because there
is NO sequence point in the former, whereas in the latter there is
one at the comma.
Victor
Many thanks to all of you,
I did find an answer in the FAQ that clarified the described situation.
Best regards,
Dmitriy Iassenev.
"Howard" <al*****@hotmail.com> wrote in message
news:bl********@dispatch.concentric.net...
You think wrong. The above is undefined behavior. You try to change
the value of a variable more than once with an intervening sequence point. The compiler is allowed to do whatever it wants, including formatting your
harddisk. Search for sequence point i+++++i on Google. One page is:
Oh, good point. I forgot about sequence points.
But regardless of what "undefined behavior" means in the standard, you had
best not sell me a compiler that formats my hard drive if I screw up
simple code like this...I know a good lawyer! :-)
So if I sell you a chain saw, and due to your ignorance
you cut off your hand, you'll sue me? I suppose so.
Only in America. :-)
-Mike
Howard wrote: You think wrong. The above is undefined behavior. You try to
change the value of a variable more than once with an intervening
sequence point. The compiler is allowed to do whatever it wants,
including formatting your harddisk. Search for sequence point
i+++++i on Google. One page is:
Oh, good point. I forgot about sequence points.
But regardless of what "undefined behavior" means in the standard,
you had best not sell me a compiler that formats my hard drive if I
screw up simple code like this...I know a good lawyer! :-)
That is outside of the topic of this newsgroup. It belongs to QoI (Quality
of Implementation). ;-)
--
WW aka Attila
Fao, Sean wrote: Wrong. modifying the same variable twice in the same expression in
undefined so anything could happen.
Yeah. Last time I have tried I have laid an egg and a politician told the
truth on national TV. ;-)
--
WW aka Attila
> So if I sell you a chain saw, and due to your ignorance you cut off your hand, you'll sue me?
Of course. First I'd sue you, pay my lawyer, declare bankruptcy, and avoid
your counter-suit. This is America after all.
"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:Al******************@newsread4.news.pas.earth link.net...
"Howard" <al*****@hotmail.com> wrote in message
news:bl********@dispatch.concentric.net... But regardless of what "undefined behavior" means in the standard, you
had best not sell me a compiler that formats my hard drive if I screw up
simple code like this...I know a good lawyer! :-)
So if I sell you a chain saw, and due to your ignorance
you cut off your hand, you'll sue me? I suppose so.
Only in America. :-)
-Mike
:-)
Funny, but a bit ludicrous, Mike. If I buy a chain saw, I know it has the
capability to cut off my hand (or anything else) if I abuse it. After all,
it is DESIGNED to cut things off! However, writing a compiler that
translates the standard's meaing of "undefined behavior" into "I can format
his hard drive if I want" is an act of malice, or at least negligence, and
would definitely be actionable in a court of law (and probably not just in
the US either). Do you write programs that, if the user does not read and
understand your user's manual correctly, will format their hard drive? If
so, please let me know what products you produce so I can avoid them! :-)
As a side note, the reason I brought this up is that that statement about
formatting someone's hard drive when undefined behavior is invoked is used
quite often in this newsgroup, but is, in my opinion, very misleading. The
standard may state that a specific type of coding constitutes undefined
behavior under the standard, but that does NOT mean anyone actually writes
compilers that take malicious or bizarre actions under those circumstances.
Compiler writers have customers that must be satisfied, and some (if not
all) of those customers are BOUND to make mistakes sometimes. It is an
imperative that they take at least "reasonable" actions when undefined
behavior is encountered (assuming that they understand and can detect those
conditions in the first place). Failure to do so will lose them customers,
and money, FAST! (Now, if there are any compiler WRITERS out there that
disagree, please let us know. :-))
How about, when telling posters about the meaning of "undefined behavior",
we leave it at that, and don't insinuate (or outright state) that they're
going to lose their hard drive if they make a mistake, ok?
-Howard
Howard wrote: Funny, but a bit ludicrous, Mike. If I buy a chain saw, I know it has the
capability to cut off my hand (or anything else) if I abuse it. After all,
it is DESIGNED to cut things off! However, writing a compiler that
translates the standard's meaing of "undefined behavior" into "I can format
his hard drive if I want" is an act of malice, or at least negligence,
What you apparently fail to realize is that the compiler *cannot* detect
undefined behavior in general, and thus cannot assign behavior to it,
nor can a compiler control what happens in the computer system when a
program attempts to do something it shouldn't. Consider DOS systems with
no memory protection. What happens if you overwrite a random memory area
with a random value? Just about anything is possible, as with undefined
behavior in general.
According to Richard Heathfield in _C Unleashed_, page 68-69:
Nasal Demons
The two most dramatic results of undefined behavior I have personally
witnessed both involved leaving insufficient room in a char array for
the terminating null character of a string.
The first occasion was in 1989, and the victim was my brother, Steve. He
(ahem) drew my attention to his screen, which was displaying a message
asking him to confirm that he wanted to format his hard disk. He was
lucky -- he was asked.
A year or so later, a colleague of mine (hi, Kevin) wasn't quite so
lucky. The first sign of his program's undefined behavior was that his
machine hung. The second sign was that it wouldn't reboot! He had to
spend quite some time nursing the machine back to health using the
diagnostic floppies supplied by the manufacturer.
I've never had anything that bad happen to me. In a way, I've been
fortunate. I would love to bring you a really embarrassing first-hand
account of how I brought down a major government by dereferencing a NULL
pointer or flooded a city by passing (UCHAR_MAX + 1) to isupper(). My
own bugs have been far less dramatic. Sorry to disappoint you.
<snip>
As a side note, the reason I brought this up is that that statement about
formatting someone's hard drive when undefined behavior is invoked is used
quite often in this newsgroup, but is, in my opinion, very misleading.
It's not even remotely misleading. According to the standard it is
perfectly possible and permissible. Real life is off-topic here (but
note, from the quote above, that this *does* happen in real life).
The
standard may state that a specific type of coding constitutes undefined
behavior under the standard, but that does NOT mean anyone actually writes
compilers that take malicious or bizarre actions under those circumstances.
Never was the claim.
Compiler writers have customers that must be satisfied, and some (if not
all) of those customers are BOUND to make mistakes sometimes. It is an
imperative that they take at least "reasonable" actions when undefined
behavior is encountered (assuming that they understand and can detect those
conditions in the first place).
Which they cannot.
Failure to do so will lose them customers,
and money, FAST! (Now, if there are any compiler WRITERS out there that
disagree, please let us know. :-))
How about, when telling posters about the meaning of "undefined behavior",
we leave it at that, and don't insinuate (or outright state) that they're
going to lose their hard drive if they make a mistake, ok?
They could. We shouldn't warn them? They're free to weigh the risk
themselves.
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting. What you apparently fail to realize is that the compiler *cannot* detect
undefined behavior in general, and thus cannot assign behavior to it,
nor can a compiler control what happens in the computer system when a
program attempts to do something it shouldn't. under those circumstances.
The
standard may state that a specific type of coding constitutes undefined
behavior under the standard, but that does NOT mean anyone actually
writes compilers that take malicious or bizarre actions under those
circumstances.
Never was the claim.
I understand your point(s) very well. But look at what I was responding to
again:
The
compiler is allowed to do whatever it wants, including formatting your
harddisk.
It very clearly states the the compler is "allowed" to do whatever it wants.
Well, as I said in my post, a compiler that does "whatever it wants",
especially if it reformats your hard drive because of a coding error, is not
a compiler that will sell very well, because people's hard drives will
ineveitably get reformatted.
-Howard
On 03 Oct 2003 18:12:38 GMT, "Howard" <al*****@hotmail.com> wrote: It very clearly states the the compler is "allowed" to do whatever it wants.
And it is! The warranty for a compiler doesn't restrict the effect of
programs that contain bugs, and probably doesn't very much for
programs that don't contain bugs.
Well, as I said in my post, a compiler that does "whatever it wants",
especially if it reformats your hard drive because of a coding error, is not
a compiler that will sell very well, because people's hard drives will
ineveitably get reformatted.
It is unlikely that a bug (read undefined behaviour) will lead to a
hdd reformat, but it has happened, and the compiler isn't to blame,
the code is.
However, the infamous DeathStation 2000 inserts code to reformat your
harddisk if you dereference a null pointer or write off the end of an
array. It hasn't sold well.
Tom
Howard wrote: What you apparently fail to realize is that the compiler *cannot* detect
undefined behavior in general, and thus cannot assign behavior to it,
nor can a compiler control what happens in the computer system when a
program attempts to do something it shouldn't. under those circumstances.
The
standard may state that a specific type of coding constitutes undefined
behavior under the standard, but that does NOT mean anyone actually
writes
compilers that take malicious or bizarre actions under those
circumstances.
Never was the claim.
I understand your point(s) very well. But look at what I was responding to
again:
The
compiler is allowed to do whatever it wants, including formatting your
harddisk.
It very clearly states the the compler is "allowed" to do whatever it wants.
Well, as I said in my post, a compiler that does "whatever it wants",
especially if it reformats your hard drive because of a coding error, is not
a compiler that will sell very well, because people's hard drives will
ineveitably get reformatted.
Yes, in that context I see your point. Though it's technically correct,
it's a quality-of-implementation issue - and any implementation with
quality that low probably won't sell. But there's a difference between
what the compiler may do (intentionally or unintentionally) and what the
code it generates might do when its behavior is undefined. In the latter
case, even the best compiler can't be expected to detect and safely
handle all instances.
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
tom_usenet wrote: However, the infamous DeathStation 2000 inserts code to reformat your
DeathStation 9000
--
WW aka Attila
Howard wrote:
It very clearly states the the compler is "allowed" to do whatever it wants.
Well, as I said in my post, a compiler that does "whatever it wants",
especially if it reformats your hard drive because of a coding error, is not
a compiler that will sell very well, because people's hard drives will
ineveitably get reformatted.
You seem to laboring under the misconception that what happens with
undefined behavior is some sort error handler the compiler installed.
That usually is not the case. Most times, you see the reaction of the
runtime environment to the UB.
I'll agree that the compiler doesn't format your hard drive with UB, but
the OS damn well might. Or it may let you scribble over other values,
silently changing them, feeding incorrect values into your nav system
and crashing your millions of dollars space probe. Quite possible, and
quite a bit worse than your formatted hard drive.
The "format your HD" is a useful way to make people think about the
situation. The idea that the system will do something sensible to cover
up your undefined behavior needs to be knocked out of their heads.
"I just used a deleted pointer, and it didn't give me a seg fault like
it's supposed to. Why?"
Brian Rodenborn
"Howard" <al*****@hotmail.com> wrote in message
news:bl********@dispatch.concentric.net...
"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:Al******************@newsread4.news.pas.earth link.net...
"Howard" <al*****@hotmail.com> wrote in message
news:bl********@dispatch.concentric.net... > But regardless of what "undefined behavior" means in the standard, you had best not sell me a compiler that formats my hard drive if I screw up
simple code like this...I know a good lawyer! :-)
So if I sell you a chain saw, and due to your ignorance
you cut off your hand, you'll sue me? I suppose so.
Only in America. :-)
-Mike
:-)
Funny, but a bit ludicrous, Mike.
Not at all.
If I buy a chain saw, I know it has the
capability to cut off my hand (or anything else) if I abuse it. After
all, it is DESIGNED to cut things off!
And the C language is designed to perform its task 'safely',
*if used according to instructions*, just like a chain saw.
The consequences of misuse, whether intentional or inadvertent,
cannot be reasonably blamed upon the manufacturer of either.
However, writing a compiler that
translates the standard's meaing of "undefined behavior" into "I can
format his hard drive if I want" is an act of malice, or at least negligence,
That is not what I said. "Undefined behavior" by definition,
is *undefined*. There is no 'translation'. The language
definition, when it indicates that its misuse results in
undefined behavior, it is essentially saying 'out of my
hands', I'm no longer responsible for the behavior of the
program. The language definition *specifically identifies*
which such misuses fall into this category. I.e. *you've
beeen warned.*
E.g. if language misuse results in an OS getting a spurious
'instruction' to format a disk, set the monitor on fire or
whatever, one cannot reasonably blame the manufacturer
or vendor of the language implementation.
"Intentional" behavior is by definition, 'defined'.
and
would definitely be actionable in a court of law (and probably not just in
the US either).
You're assigning meaning where there is none.
Do you write programs that, if the user does not read and
understand your user's manual correctly, will format their hard drive?
Of course not. You're missing the point.
If
so, please let me know what products you produce so I can avoid them! :-)
Here, run this:
int main()
{
int i;
if(i == 42)
++i = i++;
return 69;
}
:-)
As a side note, the reason I brought this up is that that statement about
formatting someone's hard drive when undefined behavior is invoked is used
quite often in this newsgroup, but is, in my opinion, very misleading.
I don't think so. I think it's a good way to convey an
example *possible* serious consequence of undefined
behavior. IMO many will of course naturally dismiss
the ubiquitous 'nasal demons' example as simple
facetiousness. An example of a real catastrophe
is imo more representative of possible consequences
of undefined behavior, and imo is a better incentive
for being careful.
If you get into your car, put it in gear, close
your eyes, and open the throttle, the consequences
will be "undefined". E.g. nothing bad might happen,
or you might end up killing several people. The
manufacturer of the car cannot rationally be held
responsible (except of course in U.S. courts. :-)).
I've never seen a car's owner manual specifically
warn against driving without watching where you're
going.
The
standard may state that a specific type of coding constitutes undefined
behavior under the standard, but that does NOT mean anyone actually writes
compilers that take malicious or bizarre actions under those
circumstances.
You miss the point. Such actions will not be those of the
compiler, but of entites and/or circumstances which *by
definition*, are outside its control.
Compiler writers have customers that must be satisfied, and some (if not
all) of those customers are BOUND to make mistakes sometimes.
And these mistakes are the responsibility of the *user*,
not of the maker of the misused product.
It is an
imperative that they take at least "reasonable" actions when undefined
behavior is encountered
By definition, undefined behavior, is *undefined*,
*outside the control of the compiler*.
I can ask you "If you're standing on a balconey above
a crowd, holding a knife, and drop the knife over the
rail, what will happen?"
What will you answer? Probably something like "Someone
might get hurt." So I tell you, "the consequences cannot
be known, although there's a good probability that something
bad will happen, so be careful, and of course don't do it
intentionally." So you somehow inadvertently drop the knife,
injuring or killing someone. Will you blame the manufacturer
of the knife?
(assuming that they understand and can detect those
conditions in the first place).
Here's where your argument really falls apart. *Undefined*
implies "cannot predict the outcome."
Failure to do so will lose them customers,
and money, FAST!
Yes, intentional malice should cause loss of business,
and possibly legal action. But what you're saying is
like saying that your boat's manufacturer is responsible
when it sinks or capsizes because you've overloaded it,
disregarding any warnings about such in its owners manual.
(Now, if there are any compiler WRITERS out there that
disagree, please let us know. :-))
I think any rational person will disagree with your
argument.
How about, when telling posters about the meaning of "undefined behavior",
Please look up the dictionary meaning of 'undefined'.
You'll see something like "unknown", or "with no meaning".
So what could possibly be the "meaning" of something
without meaning?
we leave it at that,
I rarely leave unfounded or incorrect assertions 'at that'.
and don't insinuate (or outright state) that they're
going to lose their hard drive
Nobody said they *will*, we (accurately) say they *could*,
and advise caution.
if they make a mistake, ok?
We're trying to convey the possible serious consequences
of such mistakes. Since "undefined behavior" means
*anything* can happen, of course this includes catastrophe,
as well as no problems at all. IMO it would be irresponsible
to *not* warn about this.
-Mike
Mike Wahler wrote: I don't think so. I think it's a good way to convey an
example *possible* serious consequence of undefined
behavior. IMO many will of course naturally dismiss
the ubiquitous 'nasal demons' example as simple
facetiousness. An example of a real catastrophe
is imo more representative of possible consequences
of undefined behavior, and imo is a better incentive
for being careful.
The Ariane came down due to underfined behavior. I think it was worse than
a formatted hard drive. :-(
--
WW aka Attila
"WW" <wo***@freemail.hu> wrote in message
news:bl**********@phys-news1.kolumbus.fi... Mike Wahler wrote: I don't think so. I think it's a good way to convey an
example *possible* serious consequence of undefined
behavior. IMO many will of course naturally dismiss
the ubiquitous 'nasal demons' example as simple
facetiousness. An example of a real catastrophe
is imo more representative of possible consequences
of undefined behavior, and imo is a better incentive
for being careful.
The Ariane came down due to underfined
So we need to increase the amount of the fine. :-)
behavior.
I think it was worse than
a formatted hard drive. :-(
Splatted hard dive. :-)
-Mike
"Default User" <fi********@company.com> wrote in message
news:3F***************@company.com... Howard wrote:
It very clearly states the the compler is "allowed" to do whatever it
wants. Well, as I said in my post, a compiler that does "whatever it wants",
especially if it reformats your hard drive because of a coding error, is
not a compiler that will sell very well, because people's hard drives will
ineveitably get reformatted.
You seem to laboring under the misconception that what happens with
undefined behavior is some sort error handler the compiler installed.
That usually is not the case. Most times, you see the reaction of the
runtime environment to the UB.
I'll agree that the compiler doesn't format your hard drive with UB, but
the OS damn well might. Or it may let you scribble over other values,
silently changing them, feeding incorrect values into your nav system
and crashing your millions of dollars space probe. Quite possible, and
quite a bit worse than your formatted hard drive.
The "format your HD" is a useful way to make people think about the
situation. The idea that the system will do something sensible to cover
up your undefined behavior needs to be knocked out of their heads.
"I just used a deleted pointer, and it didn't give me a seg fault like
it's supposed to. Why?"
Why does everyone keep thinking I'm not understanding what undefined
behavior means???? I was responding to a very specific statement, which
said, and I quote (AGAIN):
"The compiler is allowed to do whatever it wants, including formatting your
harddisk."
That's all I was responding to...that person's clain the the compiler was
"allowed" to reformat my hard drive. And my response was that if someone
wrote a compiler that intentionaly reformatted my hard drive, I would sue.
(And I also added that such a compiler would not sell very well.)
-Howard
AAARRRGGH Would you just read my earlier response to WW, and the specific
statement I was responding to? WW stated the following:
"The compiler is allowed to do whatever it wants, including formatting your
harddisk."
This very explicitly is talking about an action by the compiler, and all I
said was that if someone wrote their compiler so that it intentionally DID
reformat my hard drive, I'd sue. And I followed the point with a smiley
face! A joke, see????????
BTW, I FULLY agree that there is no guarantee that your hard drive WON'T be
reformatted if you invoke undefined behavior. I just suggested that
compiler writers not make such an action simply because it is "allowed to do
whatever it wants".
Now can I please get on with my life? :-)
-Howard
Howard wrote:
AAARRRGGH Would you just read my earlier response to WW, and the specific
statement I was responding to? WW stated the following:
"The compiler is allowed to do whatever it wants, including formatting your
harddisk."
In the future, please make your rants more specific. Say, "the compiler
don't do jack when it's undefined behavior, it's the system" (your
choice of idiom is wide open, of course). Then we'd understand the
target of the rant.
Now can I please get on with my life? :-)
We'll see about that.
Brian Rodenborn
"Howard" <al*****@hotmail.com> wrote in message
news:bl********@dispatch.concentric.net...
AAARRRGGH Would you just read my earlier response to WW, and the specific
statement I was responding to?
I did, but note that usenet message propagation is not
serial. Attila's reply was not visible on my server
when I responded to your post.
WW stated the following:
"The compiler is allowed to do whatever it wants, including formatting
your harddisk."
This very explicitly is talking about an action by the compiler, and all I
This remark was poorly phrased.
said was that if someone wrote their compiler so that it intentionally DID
reformat my hard drive, I'd sue. And I followed the point with a smiley
face! A joke, see????????
One moment while I laugh. :-)
But no, imo nobody (at least in the U.S.) can safely disregard as
humorous any threat of litigation, no matter how 'far-fetched'
it might seem. There is a whole industry based upon extracting
values from innocents based upon groundless claims. Often
called "ambulance chasers". Their trade is kept alive by
dishonest judges. Have you forgotten McDonald's and hot
coffee?
BTW, I FULLY agree that there is no guarantee that your hard drive WON'T
be reformatted if you invoke undefined behavior.
I think that was the point he was making, perhaps poorly.
I just suggested that
compiler writers not make such an action simply because it is "allowed to
do whatever it wants".
Technically, no it's not allowed to do "whatever it wants",
but it is relieved of the responsibility of controlling or
preventing "whatever" behavior which might occur as a result
of using constructs specified to have undefined behavior.
Now can I please get on with my life? :-)
Of course. You don't feel an obligation to respond
to anyone who might disagree with you, do you? :-)
-Mike
> Why does everyone keep thinking I'm not understanding what undefined behavior means????
Maybe because you keep harping on what the *compiler* does (in spite of
someone reference to it). Undefined behaviour happens at *runtime*. There is
*no* compiler involved. Your comments about a compiler formatting your drive
and you suing clearly indicate you don't understand what undefined behavour
is (in addition to your comment that such a compiler "would not sell very
well"). You may have only been joking but a compiler will *not* format your
drive or do any other harm. It's just a parser that turns symbolic code into
machine language (or perhaps some other intermediate form). Only at runtime
will undefined behaviour actually manifest itself. If you understood that
even now then why in your very last post (at this writing) did you say "I
just suggested that compiler writers not make such an action simply because
it is "allowed to do whatever it wants". They don't. It's the runtime
environment that's the problem and by this time the compiler is long gone.
Mike Wahler wrote: of undefined behavior, and imo is a better incentive
for being careful.
The Ariane came down due to underfined
So we need to increase the amount of the fine. :-)
Hey! Coolest typo I have ever had!
:-0
--
WW aka Attila
Howard wrote: Why does everyone keep thinking I'm not understanding what undefined
behavior means????
I do because I'm mean. I was thinking to be median, but then all these
headaches... ;-)
IMO because what you write sounds like playing it down. And it is a serious
issue. And unless we tell to newbies that they will go blind and grow hair
on their palms they will keep doing undefined behavior.
--
WW aka Attila
Howard wrote: AAARRRGGH Would you just read my earlier response to WW, and the
specific statement I was responding to? WW stated the following:
"The compiler is allowed to do whatever it wants, including
formatting your harddisk."
This very explicitly is talking about an action by the compiler, and
all I said was that if someone wrote their compiler so that it
intentionally DID reformat my hard drive, I'd sue.
Intentionally? "The compiler is allowed to do whatever it wants". Blame it
on my English. But I did not mean that the compiler will do it during
compilation. And I definitely did not mean it was/will be intentional! But
even if it would be - it would be still conforming. And - strictly
speaking - you would have a hard time to sue, since you have been warned.
--
WW aka Attila
Howard wrote: "The compiler is allowed to do whatever it wants, including
formatting your harddisk."
This very explicitly is talking about an action by the compiler, and
No, it is not. The compiler makes the program. The program makes something
causing your hard drive to be formatted and your dog to have 7 puppies and
your mother-in-law to move in permanently with her 4 deaf friends. So no,
it did not. Honest.
--
WW aka Attila
On 03 Oct 2003 17:13:36 GMT, "Howard" <al*****@hotmail.com> wrote in
comp.lang.c++:
"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:Al******************@newsread4.news.pas.earth link.net...
"Howard" <al*****@hotmail.com> wrote in message
news:bl********@dispatch.concentric.net...
> But regardless of what "undefined behavior" means in the standard, you had best not sell me a compiler that formats my hard drive if I screw up
simple code like this...I know a good lawyer! :-)
So if I sell you a chain saw, and due to your ignorance
you cut off your hand, you'll sue me? I suppose so.
Only in America. :-)
-Mike
:-)
Funny, but a bit ludicrous, Mike. If I buy a chain saw, I know it has the
capability to cut off my hand (or anything else) if I abuse it. After all,
it is DESIGNED to cut things off! However, writing a compiler that
translates the standard's meaing of "undefined behavior" into "I can format
his hard drive if I want" is an act of malice, or at least negligence, and
would definitely be actionable in a court of law (and probably not just in
the US either). Do you write programs that, if the user does not read and
understand your user's manual correctly, will format their hard drive? If
so, please let me know what products you produce so I can avoid them! :-)
Nonsense. Windows trashes many peoples hard drives, requiring a
reinstall at best, sometimes a reformat and reinstall. Have you tried
suing Microsoft?
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Jack Klein wrote: Nonsense. Windows trashes many peoples hard drives, requiring a
reinstall at best, sometimes a reformat and reinstall. Have you tried
suing Microsoft?
US states did. And they are currently being sued for their lack of
security. If that goes well I am sure they will be sued for lack of
robustness.
--
WW aka Attila
WW> The Ariane came down due to underfined behavior. I think it was
WW> worse than a formatted hard drive. :-(
I heard a talk a few years ago about the Ariane. According to that
talk, the Ariane came down because of overly aggressive range
checking. A component was showing a reading that was out of range,
which raised an exception. That exception should not have been
capable of occuring at that time, so the safety systems responded by
calling for self-destruct.
In fact, the exception was raised from a component that was used only
at the beginning of the launch, so it made no difference at the
time it happened. If the exception had simply been ignored, everything
would have been fine.
--
Andrew Koenig, ar*@acm.org
Andrew Koenig wrote: The Ariane came down due to underfined behavior. I think it was
worse than a formatted hard drive. :-(
I heard a talk a few years ago about the Ariane. According to that
talk, the Ariane came down because of overly aggressive range
checking. A component was showing a reading that was out of range,
which raised an exception. That exception should not have been
capable of occuring at that time, so the safety systems responded by
calling for self-destruct.
In fact, the exception was raised from a component that was used only
at the beginning of the launch, so it made no difference at the
time it happened. If the exception had simply been ignored,
everything would have been fine.
My mistake. Then it was the lack of "planned cell death". More subtle.
--
WW aka Attila
On Sat, 4 Oct 2003 15:58:05 GMT, Andrew Koenig <ar*@acm.org> wrote: WW> The Ariane came down due to underfined behavior. I think it was
WW> worse than a formatted hard drive. :-(
I heard a talk a few years ago about the Ariane. According to that
talk, the Ariane came down because of overly aggressive range
checking. A component was showing a reading that was out of range,
which raised an exception. That exception should not have been
capable of occuring at that time, so the safety systems responded by
calling for self-destruct.
The exception was an overflow. It was not possible with the
Ariane-4, but the rocket in question was an Ariane-5. The code had
not been changed. Diagnostic data was sent to the main system which
interpreted it as data for navigation. As a result, some weird
navigation orders were executed. The rocket started to break up under
the stress, and the self-destruct was triggered.
In fact, the exception was raised from a component that was used only
at the beginning of the launch, so it made no difference at the
time it happened. If the exception had simply been ignored, everything
would have been fine.
Actually, it was something that was no longer necessary. It had
been necessary in the Ariane-4 (in order to restart a launch quickly),
but was not needed in the Ariane-5.
Sincerely,
Gene Wirchenko This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Ben |
last post by:
Hi all,
I'm trying to figure out how how complex map, filter and reduce work
based on the following piece of code from
http://www-106.ibm.com/developerworks/linux/library/l-prog.html :
...
|
by: Piotr Wyderski |
last post by:
Hello,
is it possible to reuse a friend operator which is defined
inside a class? I'd like to obtain the following behaviour:
class integer {
integer operator +(signed long int v) const...
|
by: DeltaOne |
last post by:
#include<stdio.h>
typedef struct test{
int i;
int j;
}test;
main(){
test var;
var.i=10;
var.j=20;
|
by: Olaf |
last post by:
I have a frameset page witch contains the myFuc() function. The
function is accessed from a page in one of the frames in the frameset.
An example is shown below.
<input...
|
by: Bruno van Dooren |
last post by:
Hi All,
i have some (3) different weird pointer problems that have me stumped. i
suspect that the compiler behavior is correct because gcc shows the same
results.
...
| | |
by: shaun roe |
last post by:
Following up from my earlier post, where I pursued the line I outlined.
Here is the MYFunc class implementation:
MyFunc::MyFunc(int i):m_i(i){
ostringstream os;
os<<"This number is "<<m_i;...
|
by: scroopy |
last post by:
Is it impossible in C++ to create an assignment operator for classes
with const data? I want to do something like this
class MyClass
{
const int m_iValue;
public:
MyClass(int...
|
by: Saizan |
last post by:
Why subclassing bool from int either __invert__ or __neg__ haven't been
overrided to produce a boolean negation? I suspect backwards
compatibility or something alike, but I still wonder..
And...
|
by: Chris LaVelle |
last post by:
I don't know the easiest way to explain this so, I'm going to give an
example of how it is today....and what I'm trying to accomplish.
in the header...
typedef struct XXX_ELEMENT_tag
{
UINT8 ...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
