Differences between version 4 and predecessor to the previous major change of UndefinedSemantics.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 4 | Last edited on Friday, August 22, 2003 12:00:11 pm | by JohnMcPherson | Revert |
| Older page: | version 2 | Last edited on Thursday, August 21, 2003 10:33:36 pm | by AristotlePagaltzis | Revert |
@@ -1,9 +1,11 @@
-Standardised languages often have "grey areas" - features or (combinations of) conditions for which no behaviour was defined. Any implementation of the standard may react however it sees fit when it encounters such a condition, either because implementors were explicitly granted such freedom by the standardisation committee, but many times simply out of necessity because this condition was overlooked (or no attention paid to).
+Standardised languages often have "grey areas" - features or (combinations of) conditions for which no behaviour was defined. Any implementation of the standard may react however it sees fit when it encounters such a condition, either because implementors were explicitly granted such freedom by the standardisation committee, but many times simply out of necessity because this condition was overlooked (or no attention paid to). Another reason for things to be undefined is simply because the standardisation committee couldn't agree on how something should behave
.
Examples of UndefinedSemantics include
* native method calls in [Java]
* #pragma defines in [C]/[C++]
* many features of [HTML]
''[Perl] is amply documented, and pretty much every obvious feature's behaviour is explicitly guaranteed by the documentation. So no, it doesn't "consist entirely of UndefinedSemantics" by a long stretch. --AristotlePagaltzis''
+
+Note that UndefinedSemantics means exactly that, if you add "#pragma explode" to your C program, you are not allowed to be surprised that your toilet exploded.
