[comp.std.c] ISO C Standard Addendum

cssrccb@cc.brunel.ac.uk (Cornelia Boldyreff) (02/09/90)

               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@knosof.co.uk or
   derek@knosof.uucp           Addendum editor
   Cornelia.Boldyreff@brunel.ac.uk     BSI C Panel covener
   neil@bsiqa.co.uk or
   neil@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.