On Sat, Feb 07, 2009 at 10:24:58PM -0600, Boyd Stephen Smith Jr. wrote: > Yay! for standards. It's one of the reasons I recommend C, which > not only has a backing standard, but also standardized bindings to > OS level interfaces. I wish the standard was freely available
http://open-std.org/jtc1/sc22/wg14/www/docs/n869/n869.txt.gz (n869.pdf.gz and n869.ps.gz also available if you prefer) This is only draft, not final version. > and under a free license, Hehe... You want to change (edit) the standard? :) I am all for it to be freely available! > but the fact that it exists puts it ahead of languages without an > established standard. > > It's good to have guarantees written is technical, but readable > prose instead of the "correct" behavior being whatever the > implementation did the first time someone complained it changed. I am not sure that standards are written in readable prose :) And C standard is one that leaves many features implementation defined, unspecified or undefined! Here is one example: #include <stdio.h> int main() { int x = 5; int y, z; y = x; y += y+++--y; printf("x=%d y=%d z=%d\n", x, y, z); return 0; } Two compiler that I installed on Debian (gcc, tcc) gives different result. Also standard can have defects too! Quote from Expert C Programming: Deep C Secret by Peter van der Linden. """ Just because it's written down in an international standard doesn't mean that it's complete, consistent, or even correct. The IEEE POSIX 1003.1-1988 standard (it's an OS standard that defines UNIX-like behavior) has this fun contradiction: "[A pathname] ... consists of at most PATH_MAX bytes, including the terminating null character."--section 2.3 "PATH_MAX is the maximum number of bytes in a pathname (not a string length; count excludes a terminating null)."--section 2.9.5 So PATH_MAX bytes both includes and does not include the terminating null! An interpretation was requested, and the answer came back (IEEE Std 1003.1-1988/INT, 1992 Edition, Interpretation number: 15, p. 36) that it was an inconsistency and both can be right (which is pretty strange, since the whole point is that both can't be right). The problem arose because a change at the draft stage wasn't propagated to all occurrences of the wording. The standards process is formal and rigid, so it cannot be fixed until an update is approved by a balloting group. This kind of error also appears in the C standard in the very first footnote, which refers to the accompanying Rationale document. In fact, the Rationale no longer accompanies the C Standard--it was deleted when ownership of the standard moved to ISO. """ Few pages later he write about readability of standard: """ True, this whole area in the standard appears to have been rendered into English from Urdu via Danish by translators who had only a passing familiarity with any of these tongues, but the standards committee was having such a good time that it seemed a pity to ruin their fun by asking for some simpler, clearer rules. """ Martin -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
