Differences between version 5 and predecessor to the previous major change of UndefinedSemantics.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 5 | Last edited on Saturday, August 23, 2003 7:51:13 am | by AristotlePagaltzis | Revert |
| Older page: | version 2 | Last edited on Thursday, August 21, 2003 10:33:36 pm | by AristotlePagaltzis | Revert |
@@ -1,9 +1,9 @@
-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, or
simply out of necessity because the committee couldn't agree on a single behaviour or just plain overlooked
this condition.
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
.
