<p>The Tartan language, designed during the process that eventually led to Ada, has a <code>disable</code> statement defined as follows:</p>
<blockquote>
<p>A disable declaration in an inner block suppresses detection of the exceptions it names. A handler clause associates recovery code with a statement that may generate an exception (see section 4.7).<br />
The disable declaration permits exceptions to be individually suppressed within a given scope. <strong>Should an exception occur when its detection is suppressed, the consequences are not defined</strong>. An exception must not be signalled or redeclared in a scope in which it is suppressed. Note that suppression of an exception is not an assertion that the condition that gives rise to the exception will not occur.</p>
<p><em>(<a href="https://kilthub.cmu.edu/articles/journal_contribution/Tartan_language_design_for_the_Ironman_requirement_reference_manual/6610256" rel="noreferrer">Tartan reference manual</a>, §6.4, emphasis mine)</em></p>
</blockquote>
<p>It seems the <code>disable</code> statement has no other purpose than to trigger undefined behavior... what is the point of such a statement?</p>

<undefined-behavior><exceptions>
What was the purpose of Tartan's "disable" statement?
CC BY-SA 4.0
2023-11-03T12:10:19.053Z
Perhaps it's meant as a "quick fix" of sorts—if some part of the code errors out in production, wrap it in a `disable` and debug it later. It allows the rest of the code to run regardless of error detection.
Someone
CC BY-SA 4.0
2023-11-03T12:58:55.807Z
@Someone The spec states that if an exception occurs the consequences are undefined, so the code may not run if the error occurs (presuming I'm reading this correctly). Which is a little strange for a debugging feature...
Ginger
CC BY-SA 4.0
2023-11-03T14:16:58.970Z
Then again, this makes sense—it's sloppily suppressing the error, which matches the sort of "quick fix" a lazy developer like me would use.
Someone
CC BY-SA 4.0
2023-11-03T15:17:03.130Z
Presumably even though the behavior is undefined according to the spec, you would know how your specific implementation of the language handles it, and it would be something that's useful rather than C/C++-style language-lawyer nonsense.
rydwolf
CC BY-SA 4.0
2023-11-03T17:57:32.597Z
My best guess would be that it's an assertion that the exception won't be thrown, i.e. an unchecked reachability hint in order to allow optimisations. But the quoted text says explicitly that it's not supposed to be that. Perhaps then the spec is written that way to allow implementors to specify the behaviour in their own ways, and then the programmer can rely on the implementor's spec for it rather than the language spec.
kaya3
CC BY-SA 4.0
2023-11-03T19:12:49.400Z
@kaya3 It's very weird to say "It doesn't assert that the exception won't occur, but if it does all bets are off."
Barmar
CC BY-SA 4.0
2023-11-04T08:58:15.217Z
This has long been a feature of languages used by Defense.  Compare with EXEC CICS PUSH HANDLE and EXEC CICS POP HANDLE. Which ignore EXEC CICS HANDLE exceptions. Presumably enough senior engineers liked having such a feature that it became mandated. The o;d PL/1 and COBOL hands especially.
mckenzm
<p>In Tartan, and some other languages at that time, error reporting mechanisms are also used for trivial things like reaching EOF and integer overflow. This isn't very clear in the reference manual, but could be seen in the examples in section 4.7:</p>
<blockquote>
<pre><code>read(file,x) { on EOF -&gt; goto Exit }
x := x+1 { on Overflow -&gt; x := 0 }
</code></pre>
</blockquote>
<p>The following is my speculation. If they happen unexpectedly, and no check is done, the code could be faulty. But if it never happens, doing the check would have some performance cost. So it might be helpful to give the user the control to turn it on and off.</p>
<p>It is a small detail that modern languages seem to not care about. Programmers seem never need it, unless they want the code to be extra safe, in which case they never turn it off. And most importantly, it doesn't seem easy to make user-defined exceptions take advantage like this, so it could only be a special case if supported.</p>

CC BY-SA 4.0
2023-11-03T18:59:54.570Z
2023-11-04T00:07:29.163Z
2023-11-04T00:07:29.163Z
user23013
CC BY-SA 4.0
2023-11-06T04:51:11.907Z
Another possible issue, though this is just speculation not really worthy of an answer, is that in some cases the construct may be analogous to "battle shorts" in fuse blocks in some military vehicles.  Normally, most vehicles, military or civilian, protect their circuits with fuses that will blow in case of overload, but some kinds of military equipment allow all such protections to be bypassed.  The basic idea is that if a short circuit occurs in some sections of wiring during combat, bad things would be almost certain to happen if a fuse blows, and the consequences of bypassing the fuse...
supercat
CC BY-SA 4.0
2023-11-06T04:57:53.180Z
...would be slightly more likely to be survivable for the crew than having the fuse interrupt current.  In many cases, having a system fail safely 100% of the time a condition arises may be better than having it succeed 90% the time the condition arises and fail dangerously the other 10%, but in some circumstances, it would be better for a system to have a 99% chance of failing in the worst possible way and a 1% chance of success, than to have a 100% chance of it failing in the least harmful way.  Consider the New Horizons probe.  Failsafes were disabled as it approached Pluto...
supercat
CC BY-SA 4.0
2023-11-06T05:01:52.180Z
...since a failsafe mechanism which resulted in the craft's operation being impaired for 20 minutes during the Pluto fly-by, but then allowed resumption fo communication after that, would if triggered be almost as bad as a failure which resulted in permanent loss of communication.  For vehicles near Earth, avoiding crashing into things must be of maximum priority, but for something like the New Horizons probe, physics would make it impossible for even the most malicious software upload to cause the craft to hit something on Earth.
supercat
<p>Although &quot;performance reasons&quot;, as described in other answers, seems like an adequate explanation for why it would make sense to turn off error checks, I think it's also important to recognize that our modern understanding of &quot;undefined behavior&quot; has evolved a lot over time. My guess is that, at the time this was written (1978), it would have been understood to mean &quot;whatever the implementation happens to do is fine, and whatever values happen to come out are fine&quot;. That is, I think it would have been closer to what we now would called &quot;unspecified&quot; or &quot;implementation defined&quot; behavior, rather than today's &quot;nasal demons&quot; definition of undefined behavior.</p>
<p>Even if the latter was technically a possible reading back then, probably nobody would read it that way, because it would have been fairly academic before the advent of today's hyper-aggressive optimizing compilers.</p>

CC BY-SA 4.0
2023-11-04T21:26:13.917Z
2023-11-04T21:26:13.917Z
Glenn Willen
CC BY-SA 4.0
2023-11-04T21:29:31.063Z
I'm not sure that "undefined behaviour" didn't also mean "nasal demons" in 1978. I think the reason for having undefined behaviour is the same.
pxeger
CC BY-SA 4.0
2023-11-04T21:37:33.983Z
The actual phrase "nasal demons" was not coined until 1992. I _think_ our modern definition of "undefined" comes from the C standard, which was first officially published in 1989, but I don't know if the current definition of undefined behavior was first found in that document, or some earlier or later one.
Glenn Willen
CC BY-SA 4.0
2023-11-04T21:40:36.000Z
Actually, even the first _unofficial_ specification of the C language wasn't published until 1978. So if "undefined means no rules" comes originally from C, it can't predate that. It's possible C imported it from another language, but I'm not sure that languages having official standards/specification documents had even really caught on much yet, at that time?
Glenn Willen
CC BY-SA 4.0
2023-11-04T21:45:10.547Z
The language is explicitly prohibited from guaranteeing the integrity of values when suppressed exceptions occur, though, which is a bit beyond "implementation-defined".
Michael Homer
CC BY-SA 4.0
2023-11-04T21:45:39.890Z
From what I can tell, assuming my PDF of "The C Programming Language" from 1978 is correctly OCRed, it doesn't appear to contain the concept of "undefined behavior". This leads me to believe our current definition did not exist at that time.
Glenn Willen
CC BY-SA 4.0
2023-11-04T21:48:47.540Z
@michaelhomer Integrity of _values_, which seems to me a critical distinction. Under the C definition of undefined behavior, any instance of undefined behavior anywhere in an entire program automatically renders the entire program undefined. No part of it has any meaning or is guaranteed to do anything specific. My interpretation of "integrity of values" is that the result of the undefined computation may be wrong. This does not, to me, seem to imply that the entire program could format your hard drive, or send your nudes to CNN, in compliance with the standard.
Glenn Willen
CC BY-SA 4.0
2023-11-04T21:49:19.233Z
That would seem to make it at worst more equivalent to "unspecified" in C, rather than "undefined".
Glenn Willen
CC BY-SA 4.0
2023-11-05T19:57:21.780Z
@pxeger: Many programmers might find implausible that code which performs a stray pointer read could cause disk corruption, but on one of the more popular computers throughout 1980s (the Apple II series, with six million units sold in a ~15 year period) that was indeed the case.  It was thus important for programmers to be aware that many actions which would harmless on most hardware platforms might have disastrous consequences on some.
supercat
CC BY-SA 4.0
2023-11-05T20:00:04.113Z
@GlennWillen: I think it would have been recognized that of the actions in question might cause optimizing code-reordering transforms to be observable.  In the C Standard, only actions which are characterized as invoking Undefined Behavior can result in behavior inconsistent with sequential program execution, but the behaviors described were probably intended to be far more localized than "modern UB".
supercat
CC BY-SA 4.0
2023-11-05T20:02:40.107Z
@GlennWillen: I find particularly interesting the bracketed note: "Note that suppression of an exception is not an assertion that the corresponding error will not occur."  That expressly forbids some kinds of "optimizations" favored by [passive-]aggressive compiler writers.
supercat
CC BY-SA 4.0
2023-11-08T21:22:25.393Z
@pxeger: There's a big difference between saying that actions which behave usefully and predictably on commonplace hardware platforms may behave in dangerously unexpected fashion (releasing nasal demons) on some obscure ones, and saying that compilers should feel free to process code in ways that would release nasal demons even when targeting commonplace platforms that had historically processed the actions usefully.
supercat
<p>The purpose of this feature <em>in Tartan</em> is to satisfy the <a href="https://apps.dtic.mil/sti/pdfs/ADA100403.pdf" rel="noreferrer">Ironman requirement 10G</a>:</p>
<blockquote>
<p>10G. Suppressing Exceptions. It shall be possible to suppress individually the
detection of exceptions for software error situations. Should such a situation
occur when its detection is suppressed, the consequences will be unpredictable</p>
</blockquote>
<p>The &quot;Strawman&quot;, &quot;Woodenman&quot;, &quot;Tinman&quot; and &quot;Ironman&quot; versions of the <em>Department of Defense Requirements for High Order Computer Programming Languages</em> were released in sequence as part of that Ada development process. As the abstract of the Tartan paper notes, minimally satisfying all of the Ironman requirements was the primary goal of that language design.</p>
<p>In fact, the specification statement is exactly in the terms of the subsequent <a href="https://web.archive.org/web/20200914235620/https://dwheeler.com/steelman/steelman.htm" rel="noreferrer">Steelman</a> requirements, which had recently become available:</p>
<blockquote>
<p>10G. Suppressing Exceptions. It shall be possible during translation to suppress individually the execution time detection of exceptions within a given scope. The language shall not guarantee the integrity of the values produced when a suppressed exception occurs. [Note that suppression of an exception is not an assertion that the corresponding error will not occur.]</p>
</blockquote>
<hr />
<p>The reason <em>those</em> requirements specified that detection of exceptional conditions should be able to be locally disabled was that the run-time costs of validating them could be significant on typical period hardware, such as requiring range checks on every access to a variable. This is explicit in requirement 10B:</p>
<blockquote>
<p>10B. Error Situations. The errors detectable during execution shall include exceeding the specified range of an array subscript, exceeding the specified range of a variable, exceeding the implemented range of a variable, <em>[...elided...]</em>. <strong>[Note that some are very expensive to detect unless aided by special hardware, and consequently their detection will often be suppressed (see 10G).]</strong></p>
</blockquote>
<p>Thus a program could opt to avoid incurring these checks for a portion of the code where the performance cost of detecting them was unacceptable, either because that error was known not to occur or because the implementation's behaviour was acceptable in the cases where it did. This also made it into the final Ada definition in the form of the <a href="https://www.adaic.com/resources/add_content/standards/05rm/html/RM-11-5.html" rel="noreferrer">Suppress pragma</a>, for the same reasons.</p>
<hr />
<ul>
<li><sub>Department of Defense Requirements for High Order Computer Programming Languages, &quot;Ironman&quot;. 14 January 1977. ADA100403. (alternative <a href="https://archive.org/details/DTIC_ADA100403" rel="noreferrer">archive.org version</a>)</sub></li>
<li><sub>Department of Defense Requirements for High Order Computer Programming Languages, &quot;Steelman&quot;. 1 June 1978. ADA059444. (alternative <a href="https://en.wikisource.org/wiki/Steelman_language_requirements" rel="noreferrer">wikisource text copy</a>)</sub></li>
</ul>

CC BY-SA 4.0
2023-11-03T20:52:37.823Z
2023-11-04T02:28:56.640Z
2023-11-04T02:28:56.640Z
Michael Homer
CC BY-SA 4.0
2023-11-04T01:15:52.487Z
The link to the Ironman document link is borked for me -- it starts to show the PDF viewer but then I get an error loading page.
Bbrk24
CC BY-SA 4.0
2023-11-04T01:24:08.067Z
It’s a working link to a regular PDF as far as I can tell, but the document is called “Department of Defense Requirements for High Order Computer Programming Languages”, 14 January 1977, and you can find it elsewhere too.
Michael Homer
CC BY-SA 4.0
2023-11-04T01:35:56.973Z
When I look it up, I see "This document is not available in digital form. If you are supporting DoD or U.S. Government research please Sign In using a CAC, PIV or ECA or register with DTIC. Once registered, sign in, search for your document, and click on “Request Scanned Document”. If you are ineligible to register, you can request this document through FOIA." Are you logged in or on a VPN, perchance?
Bbrk24
CC BY-SA 4.0
2023-11-04T01:52:21.110Z
Surprisingly, my house does not have privileged access to United States military information. This URL is in search engines (which is where I found the right version) so I don't think it's meant to be hidden at all. There is an archive.org version [here](https://archive.org/details/DTIC_ADA100403) that appears to be the same scan.
Michael Homer
CC BY-SA 4.0
2023-11-04T14:01:36.813Z
Loads fine for me. Could be a region-dependent issue.
user2357112
CC BY-SA 4.0
2023-11-05T17:55:56.917Z
Also loads fine for me. Even though appears to be scan of a printed document, the text is actually searchable (when opened the URL using Chrome).
Chester Gillon
# What was the purpose of Tartan's "disable" statement?
Posted by: username_0 on 2023-11-03
The Tartan language, designed during the process that eventually led to Ada, has a `disable` statement defined as follows:

> A disable declaration in an inner block suppresses detection of the exceptions it names. A handler clause associates recovery code with a statement that may generate an exception (see section 4.7).  
> The disable declaration permits exceptions to be individually suppressed within a given scope. **Should an exception occur when its detection is suppressed, the consequences are not defined**. An exception must not be signalled or redeclared in a scope in which it is suppressed. Note that suppression of an exception is not an assertion that the condition that gives rise to the exception will not occur.
>
> *([Tartan reference manual](https://kilthub.cmu.edu/articles/journal_contribution/Tartan_language_design_for_the_Ironman_requirement_reference_manual/6610256), §6.4, emphasis mine)*

It seems the `disable` statement has no other purpose than to trigger undefined behavior... what is the point of such a statement?
**Tags:** undefined-behavior exceptions
> **Comments:**
> **username_1**: Perhaps it's meant as a "quick fix" of sorts—if some part of the code errors out in production, wrap it in a `disable` and debug it later. It allows the rest of the code to run regardless of error detection.  
> **username_2**: @Someone The spec states that if an exception occurs the consequences are undefined, so the code may not run if the error occurs (presuming I'm reading this correctly). Which is a little strange for a debugging feature...  
> **username_1**: Then again, this makes sense—it's sloppily suppressing the error, which matches the sort of "quick fix" a lazy developer like me would use.  
> **username_3**: Presumably even though the behavior is undefined according to the spec, you would know how your specific implementation of the language handles it, and it would be something that's useful rather than C/C++-style language-lawyer nonsense.  
> **username_4**: My best guess would be that it's an assertion that the exception won't be thrown, i.e. an unchecked reachability hint in order to allow optimisations. But the quoted text says explicitly that it's not supposed to be that. Perhaps then the spec is written that way to allow implementors to specify the behaviour in their own ways, and then the programmer can rely on the implementor's spec for it rather than the language spec.  
> **username_5**: @kaya3 It's very weird to say "It doesn't assert that the exception won't occur, but if it does all bets are off."  
> **username_6**: This has long been a feature of languages used by Defense.  Compare with EXEC CICS PUSH HANDLE and EXEC CICS POP HANDLE. Which ignore EXEC CICS HANDLE exceptions. Presumably enough senior engineers liked having such a feature that it became mandated. The o;d PL/1 and COBOL hands especially.  
---
## 3 answers
### Answer by username_11 on 2023-11-03. Score: 16 | Accepted answer
The purpose of this feature *in Tartan* is to satisfy the [Ironman requirement 10G](https://apps.dtic.mil/sti/pdfs/ADA100403.pdf):

> 10G. Suppressing Exceptions. It shall be possible to suppress individually the
> detection of exceptions for software error situations. Should such a situation
> occur when its detection is suppressed, the consequences will be unpredictable

The "Strawman", "Woodenman", "Tinman" and "Ironman" versions of the *Department of Defense Requirements for High Order Computer Programming Languages* were released in sequence as part of that Ada development process. As the abstract of the Tartan paper notes, minimally satisfying all of the Ironman requirements was the primary goal of that language design.

In fact, the specification statement is exactly in the terms of the subsequent [Steelman](https://web.archive.org/web/20200914235620/https://dwheeler.com/steelman/steelman.htm) requirements, which had recently become available:

> 10G. Suppressing Exceptions. It shall be possible during translation to suppress individually the execution time detection of exceptions within a given scope. The language shall not guarantee the integrity of the values produced when a suppressed exception occurs. [Note that suppression of an exception is not an assertion that the corresponding error will not occur.]

---

The reason *those* requirements specified that detection of exceptional conditions should be able to be locally disabled was that the run-time costs of validating them could be significant on typical period hardware, such as requiring range checks on every access to a variable. This is explicit in requirement 10B:

> 10B. Error Situations. The errors detectable during execution shall include exceeding the specified range of an array subscript, exceeding the specified range of a variable, exceeding the implemented range of a variable, *[...elided...]*. **[Note that some are very expensive to detect unless aided by special hardware, and consequently their detection will often be suppressed (see 10G).]**

Thus a program could opt to avoid incurring these checks for a portion of the code where the performance cost of detecting them was unacceptable, either because that error was known not to occur or because the implementation's behaviour was acceptable in the cases where it did. This also made it into the final Ada definition in the form of the [Suppress pragma](https://www.adaic.com/resources/add_content/standards/05rm/html/RM-11-5.html), for the same reasons.

---

* Department of Defense Requirements for High Order Computer Programming Languages, "Ironman". 14 January 1977. ADA100403. (alternative [archive.org version](https://archive.org/details/DTIC_ADA100403))
* Department of Defense Requirements for High Order Computer Programming Languages, "Steelman". 1 June 1978. ADA059444. (alternative [wikisource text copy](https://en.wikisource.org/wiki/Steelman_language_requirements))
> **Comments:**
> **username_12** (2023-11-04): The link to the Ironman document link is borked for me -- it starts to show the PDF viewer but then I get an error loading page.  
> **username_11** (2023-11-04): It’s a working link to a regular PDF as far as I can tell, but the document is called “Department of Defense Requirements for High Order Computer Programming Languages”, 14 January 1977, and you can find it elsewhere too.  
> **username_12** (2023-11-04): When I look it up, I see "This document is not available in digital form. If you are supporting DoD or U.S. Government research please Sign In using a CAC, PIV or ECA or register with DTIC. Once registered, sign in, search for your document, and click on “Request Scanned Document”. If you are ineligible to register, you can request this document through FOIA." Are you logged in or on a VPN, perchance?  
> **username_11** (2023-11-04): Surprisingly, my house does not have privileged access to United States military information. This URL is in search engines (which is where I found the right version) so I don't think it's meant to be hidden at all. There is an archive.org version [here](https://archive.org/details/DTIC_ADA100403) that appears to be the same scan.  
> **username_13** (2023-11-04): Loads fine for me. Could be a region-dependent issue.  
> **username_14** (2023-11-05): Also loads fine for me. Even though appears to be scan of a printed document, the text is actually searchable (when opened the URL using Chrome).  
---
### Answer by username_7 on 2023-11-03. Score: 2
In Tartan, and some other languages at that time, error reporting mechanisms are also used for trivial things like reaching EOF and integer overflow. This isn't very clear in the reference manual, but could be seen in the examples in section 4.7:

read(file,x) { on EOF -> goto Exit }
x := x+1 { on Overflow -> x := 0 }


The following is my speculation. If they happen unexpectedly, and no check is done, the code could be faulty. But if it never happens, doing the check would have some performance cost. So it might be helpful to give the user the control to turn it on and off.
It is a small detail that modern languages seem to not care about. Programmers seem never need it, unless they want the code to be extra safe, in which case they never turn it off. And most importantly, it doesn't seem easy to make user-defined exceptions take advantage like this, so it could only be a special case if supported.
> **Comments:**
> **username_8** (2023-11-06): Another possible issue, though this is just speculation not really worthy of an answer, is that in some cases the construct may be analogous to "battle shorts" in fuse blocks in some military vehicles.  Normally, most vehicles, military or civilian, protect their circuits with fuses that will blow in case of overload, but some kinds of military equipment allow all such protections to be bypassed.  The basic idea is that if a short circuit occurs in some sections of wiring during combat, bad things would be almost certain to happen if a fuse blows, and the consequences of bypassing the fuse...  
> **username_8** (2023-11-06): ...would be slightly more likely to be survivable for the crew than having the fuse interrupt current.  In many cases, having a system fail safely 100% of the time a condition arises may be better than having it succeed 90% the time the condition arises and fail dangerously the other 10%, but in some circumstances, it would be better for a system to have a 99% chance of failing in the worst possible way and a 1% chance of success, than to have a 100% chance of it failing in the least harmful way.  Consider the New Horizons probe.  Failsafes were disabled as it approached Pluto...  
> **username_8** (2023-11-06): ...since a failsafe mechanism which resulted in the craft's operation being impaired for 20 minutes during the Pluto fly-by, but then allowed resumption fo communication after that, would if triggered be almost as bad as a failure which resulted in permanent loss of communication.  For vehicles near Earth, avoiding crashing into things must be of maximum priority, but for something like the New Horizons probe, physics would make it impossible for even the most malicious software upload to cause the craft to hit something on Earth.  
---
### Answer by username_9 on 2023-11-04. Score: 2
Although "performance reasons", as described in other answers, seems like an adequate explanation for why it would make sense to turn off error checks, I think it's also important to recognize that our modern understanding of "undefined behavior" has evolved a lot over time. My guess is that, at the time this was written (1978), it would have been understood to mean "whatever the implementation happens to do is fine, and whatever values happen to come out are fine". That is, I think it would have been closer to what we now would called "unspecified" or "implementation defined" behavior, rather than today's "nasal demons" definition of undefined behavior.

Even if the latter was technically a possible reading back then, probably nobody would read it that way, because it would have been fairly academic before the advent of today's hyper-aggressive optimizing compilers.
> **Comments:**
> **username_10** (2023-11-04): I'm not sure that "undefined behaviour" didn't also mean "nasal demons" in 1978. I think the reason for having undefined behaviour is the same.  
> **username_9** (2023-11-04): The actual phrase "nasal demons" was not coined until 1992. I _think_ our modern definition of "undefined" comes from the C standard, which was first officially published in 1989, but I don't know if the current definition of undefined behavior was first found in that document, or some earlier or later one.  
> **username_9** (2023-11-04): Actually, even the first _unofficial_ specification of the C language wasn't published until 1978. So if "undefined means no rules" comes originally from C, it can't predate that. It's possible C imported it from another language, but I'm not sure that languages having official standards/specification documents had even really caught on much yet, at that time?  
> **username_11** (2023-11-04): The language is explicitly prohibited from guaranteeing the integrity of values when suppressed exceptions occur, though, which is a bit beyond "implementation-defined".  
> **username_9** (2023-11-04): From what I can tell, assuming my PDF of "The C Programming Language" from 1978 is correctly OCRed, it doesn't appear to contain the concept of "undefined behavior". This leads me to believe our current definition did not exist at that time.  
> **username_9** (2023-11-04): @michaelhomer Integrity of _values_, which seems to me a critical distinction. Under the C definition of undefined behavior, any instance of undefined behavior anywhere in an entire program automatically renders the entire program undefined. No part of it has any meaning or is guaranteed to do anything specific. My interpretation of "integrity of values" is that the result of the undefined computation may be wrong. This does not, to me, seem to imply that the entire program could format your hard drive, or send your nudes to CNN, in compliance with the standard.  
> **username_9** (2023-11-04): That would seem to make it at worst more equivalent to "unspecified" in C, rather than "undefined".  
> **username_8** (2023-11-05): @pxeger: Many programmers might find implausible that code which performs a stray pointer read could cause disk corruption, but on one of the more popular computers throughout 1980s (the Apple II series, with six million units sold in a ~15 year period) that was indeed the case.  It was thus important for programmers to be aware that many actions which would harmless on most hardware platforms might have disastrous consequences on some.  
> **username_8** (2023-11-05): @GlennWillen: I think it would have been recognized that of the actions in question might cause optimizing code-reordering transforms to be observable.  In the C Standard, only actions which are characterized as invoking Undefined Behavior can result in behavior inconsistent with sequential program execution, but the behaviors described were probably intended to be far more localized than "modern UB".  
> **username_8** (2023-11-05): @GlennWillen: I find particularly interesting the bracketed note: "Note that suppression of an exception is not an assertion that the corresponding error will not occur."  That expressly forbids some kinds of "optimizations" favored by [passive-]aggressive compiler writers.  
> **username_8** (2023-11-08): @pxeger: There's a big difference between saying that actions which behave usefully and predictably on commonplace hardware platforms may behave in dangerously unexpected fashion (releasing nasal demons) on some obscure ones, and saying that compilers should feel free to process code in ways that would release nasal demons even when targeting commonplace platforms that had historically processed the actions usefully.  
---
