Re^2: The behavior is [sic] undefined

The standardeze I recall from C and C++ is that "implementation dependent" means something else. I.D. means that a reasonable choice may be made by the implementer, and it will behave in a consistent manner within that system. For example, whether shifting is signed or unsigned.

But undefined meant that all bets are off. It could do bizarre things including destroy the computer or make zebras fly out of the USB port. Calling through a stray pointer exhibits undefined behavior. One famous example in DOS would make the printer start spewing stuff (a failed BOUND instruction would call INT 5, if memory serves. MS decided to use that for the print-screen key instead of its intended purpose. Random garbage executed as code would hit that byte eventually.)

Since Perl 6 is more "confined" than C, I don't expect to have that very often. More usually, the implementation can choose from a range of allowed behaviors.

Sometimes, the allowed "ill-behaved" behavior is hard to pin down. For example, if you random-access a lazy list generated from a map that you promised was injective and idempotent, and the mapping block decides to return other than 1 value at some point, I can expect that list to be messed up, but the virtual machine won't crash, and strange things won't happen to global variables, etc.

—John

Comment on Re^2: The behavior is [sic] undefined Download Code

Replies are listed 'Best First'.
Re^3: The behavior is [sic] undefined by BrowserUk (Patriarch) on May 13, 2009 at 19:31 UTC
So, that leaves "the behaviour is unspecified" to describe the situation that you otherwise describe as "a shortcut for saying that the specification for the behavior is undefined.". Seems good to me. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^4: The behavior is [sic] undefined by John M. Dlugosz (Monsignor) on May 13, 2009 at 20:23 UTC
That sounds right. And hangon points out that the common meaning for "behavior" is "expected behavior". So I'm really saying that the expectation is undefined. That does seem to be how languages evolve. But when the referent is the part that got left out or left behind, it can be very annoying to more cultured ears. Like a home-improvement show says "to poly the bookcase". Er, the verb you wanted is varnish. But was "varnish" itself a noun that got turned into a verb? Apparently the word can be traced all the way back to the name of the Greek city of Κυρηναϊκή. Go figure.	[reply]
Re^3: The behavior is [sic] undefined by jdporter (Paladin) on May 15, 2009 at 02:42 UTC
It could do bizarre things including destroy the computer or make zebras fly out of the USB port. That reminds me of a post I read in `comp.std.c` a long time ago: `> Now what happens if, oh, you do THIS: > > foo() > { > int x; > > x=10; > if (x) free (&x); > } > > I know that malloc uses heap space and that the local variables take up the > stack, so what happens? &x is NOT null so it will try to free it, so what > happens? Shit happens. Exactly what shit happens depends on the implementation. Since this is in the realm of undefined behavior a conforming implementation is allowed to launch a pre-emptive strike against Iraq.` That was posted by Stanley Friesen on 1990-12-19, which is unfortunately older than what Google Groups has archived, so I can't give you a link to it. Between the mind which plans and the hands which build, there must be a mediator... and this mediator must be the heart.	[reply]