On Sunday 08 February 2009 11:04:42 Martin wrote:
> 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 very specifically *not* the standard.
> > and under a free license,
>
> Hehe... You want to change (edit) the standard? :)
> I am all for it to be freely available!
I want to be able to print it out and had it to everyone in my class. I want
to be able to take notes on it and publish them interspersed with the
standard. I want to use it as a base document for an implementation guide to
be distributed with my implementation.
Yes, I want it under a free license.
> > 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 :)
It's highly technical, and requires a glossary as part of the document, but I
do find it generally readable, if not entirely enjoyable. I do *not* curl up
with technical manuals while going to bed. :)
> And C standard is one that leaves many features implementation
> defined, unspecified or undefined!
That's on purpose, for two reasons: (1) to support multiple competing
implementations, (2) to document where implementations are allowed to differ
so programmers can avoid them if they so choose.
> y += y+++--y;
This results in implementation-specific behavior since you are modifying a
single variable twice with no sequence point in between.
> printf("x=%d y=%d z=%d\n", x, y, z);
More implementation-specific behavior as z has not be initialized.
> Two compiler that I installed on Debian (gcc, tcc) gives different result.
Different implementations are allowed to have different behavior in this case.
It's not a flaw with the standard to support multiple implementations; it's a
feature. If the programmer wants consistent results across implementations,
they can avoid the constructs that the standard says have undefined or
implementation-specific behavior.
> Also standard can have defects too!
No doubt. Standards are made by humans and they generally make mistakes.
> "[A pathname] ... consists of at most PATH_MAX bytes, including the
> terminating null character."--section 2.3
(1) bytes(pathname, INCLUDE_NULL) <= PATH_MAX
> "PATH_MAX is the maximum number of bytes in a pathname (not a string
> length; count excludes a terminating null)."--section 2.9.5
(2) PATH_MAX >= bytes(pathname, EXCLUDE_NULL).
Although, this section is somewhat self-inconsistent the "not a string length"
implies "includes the terminating null" since "a string length" "excludes a
terminating null".
> So PATH_MAX bytes both includes and does not include the terminating null!
Yes. ;)
As long as the pseudo-code (1) AND (2) are satisfied the implementation is
conformant.
> 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).
Both can be correct and are. Saying "X is the maximum of Y" means that Y
cannot be X+1, but it does NOT mean that Y can be X or even X-1.
The relationship you are looking for is called "least maximum" my
mathematicians. And, oddly enough, doesn't exist in some contexts.
> 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.
That happens anytime you need to get a large group to agree to something.
> 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.
I guess I just don't have as much trouble understanding the technical
language. Then again, when I have a question about C/C++ the first thing I
reach for is a standard, so I have a bit of experience deciphering it.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.