Differences between version 2 and previous revision of UndefinedSemantics.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 2 | Last edited on Thursday, August 21, 2003 10:33:36 pm | by AristotlePagaltzis | Revert |
| Older page: | version 1 | Last edited on Thursday, August 21, 2003 9:44:10 pm | by StuartYeates | Revert |
@@ -1,5 +1,9 @@
-[UndefinedSemantics] are semantics that are undefined
.
+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 which it makes little or no sense to standardise these are said to be areas
of [
UndefinedSemantics]. Each implementation may do whatever it wishes when a programmer used a feature or combination of features with [UndefinedSemantics].
+Examples
of UndefinedSemantics include
-native method calls have undefined semantics
in [Java],
#pragma's are have undefined semantics
in the
[C]/[C++] family of languages,
many features of [HTML] tables have undefined semantics and
[perl
] is non-standardised (I think...)
and so consists
entirely of [
UndefinedSemantics]
.
+*
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''
