ISO C Standard Addendum
Cornelia Boldyreff
cssrccb at cc.brunel.ac.uk
Sat Feb 10 02:24:08 AEST 1990
Producing an Addendum for the ISO C standard
Some background
At a joint ANSI/ISO meeting in Seattle, last year, it was
agreed that the UK would drop its NO vote on the ANSI standard, a
draft at the time, going forward as an ISO standard; provided an
addendum was produced.
The addendum as originally muted was simply going to be an informative
document, but at the ISO meeting in Berlin, at the end of last year,
it was agreed that a normative addendum was required.
Rather than publish this addendum as a separate document to read in conjunction
with the the ISO standard, it is proposed that these documents
are merged into a single text to aid users of the standard. This strategy is
similar to that being followed by WG 15 with respect to IS9945-1 (the base of
the POSIX standard) to ensure that the IEEE and ISO versions are aligned into
a single document.
The contents of the addendum will be prepared by WG14, the International
working group for C. The UK will provide the addendum editor: Derek Jones.
The current ANSI standard is still going forward as an ISO standard,
but will be superceded by the amended version which will be a merge
between the ISO DP9899 and the addendum.
A meeting of the ISO C working group, WG14, has been arranged from the
18th-19th June at the BSI in London. The idea is to start the ball
rolling on the addendum. To make this meeting productive, it is important to
do as much preparatory work on the addendum beforehand.
The UK still holds the view that any changes will be editorial in
nature. By keeping the changes to editorial it is hoped to decrease
the time taken to produce the addendum.
It is thought think that most of the changes will occur in the implicitly
undefined category. At the moment the C standard is quiet about
certain topics, relying on the "if not mentioned then undefined" rule.
The UK is soliciting 'problems' with the current ANSI standard:
A good example of the kind of input required is the thorough going
analysis about pointers that was recently posted to this news group
from au.oz.anu.csc1!bdm659.
Problems could be:
An Ambiguity: The document says x is black in one place and that
x is white in another.
Implicity undefined
behaviour : The color of y is not given.
On a number of occasions people have mentioned so-called 'problems'
with the standard which might be called 'not what we meant' statements.
Not what we
meant statement: z is black.
What we really
meant : z is black on Mondays and grey the rest of the week.
It is not intended to modify existing clearly defined statements.
A more problematic area is poor wording in the standard:
Poor wording : Twas brillig, and the slithy toves
Did gyre and gimble in the wabe;
All mimsy were the borogrives
And the mome raths outgrabe.
Some readers may consider the above unclear in its meaning. While
others will consider the meaning to be obvious.
Also for example, to rely on explanatory text in the footnotes or
in the rationale is not adequate; this text is not part of the
standard. Where an explanation is required to make the intented
meaning clear, it should be given in the text of the standard itself.
UK mail addresses:
derek at knosof.co.uk or
derek at knosof.uucp Addendum editor
Cornelia.Boldyreff at brunel.ac.uk BSI C Panel covener
neil at bsiqa.co.uk or
neil at bsqai.uucp Person responsible at British Standards Institution
for European C validation
This message was prepared by Derek Jones in collaboration with other members
of the BSI C Panel; and comments on the ANSI/ISO C standard text should be
addressed to him.
More information about the Comp.lang.c
mailing list