Re: Which programming Language
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
Reply to: