X/Open comments on dpANS C

[Dave Decot]

This is also posted to comp.std.c, but because that group is somewhat new,
I have also crossposted here.

The Kernel Working Group of the X/Open Group, Ltd. would like to make
the following eleven objections to the dpANS C Standard.  We believe
these concerns need to satisfactorily addressed in order for us to fully
support the C Standard when it is adopted.  We are much in appreciation
for all of the hard work and results produced by the committee and the
public reviewers so far.

Some of our objections may be the results of misunderstandings on our part,
because occasionally the wording in the draft is unclear.  In these
cases, it might be appropriate to add rationale or words to the dpANS C
Standard itself to clarify the issues.

The timing of this group of comments is not optimal; we realise that
the public comment period is nearly ended.

Please direct any comments to the address below.

Dave Decot, Chair 
X/Open Kernel Working Group
{ucbvax,hplabs!hpda}!sun!sunuk!inset!xopen!XoTGKern
XoTGKern at xopen.co.uk
-------

    * According to the ANSI draft, E2BIG is not in the namespace
      of allowable extensions for the <errno.h> header, but POSIX
      requires it.  We'd prefer that it be allowed.

    * It is disputable whether the new %<digit>$ argument ordering
      syntax of the NLS versions of the printf() and scanf() family
      of functions is a legitimate extension to ANSI C, since the
      draft says that "if a conversion specification is invalid,
      the behavior is undefined."  We'd prefer that it be "unspecified".

    * The disposition of the "error indicator" in the input/output
      (<stdio.h>) functions is generally unclear.  For which
      functions shall it be set?  For which shall it not be set?
      For which is the state intended to be unspecified?  What is
      its initial state?  There is no wording stating whether the
      error indicator is affected when the Standard is silent about
      its state.  For example, whether read errors during gets()
      affect the error indicator is not specified, nor is the
      silence explained in the rationale.  We'd prefer that
      an explicit statement be given for each function that
      potentially does I/O.

    * Certain return values for fflush/fclose for streams that have
      already been closed imply conditions that are (traditionally,
      at least) very difficult and awkward to detect.  The fclose()
      function says it must return EOF if the stream was already
      closed.  This seems useless to correct applications.
      Requiring that this condition be detected also seems to imply
      that fopen() must keep track of a potentially unlimited number
      of closed streams and never return any of these again, so that
      any calls to fclose() on any one of them can return EOF.  We'd
      prefer that this phrase be dropped.

    * The longjmp() function may not be invoked from a signal handler.
      This is rather sad, especially since the Standard seems to
      anticipate the possibility of invoking it from a "nested signal
      handler" under the description of longjmp().  We'd prefer to
      permit longjmp() to be called from a signal handler.

    * The traditional implementation of tmpfile() that calls
      tmpnam() is disallowed by the requirement that tmpnam()
      not behave as though any library function calls it.

    * Similarly, the definition of signal() forbids its use
      in the implementation of system() to arrange the handling
      of signals in the parent process.

    * setjmp() is required to be a macro and apparently required
      not to be a function.  We don't see why it should not be
      allowed to also be a function.

    * ANSI forbids POSIX's additional signal handling functions
      (such as sigaction()) to be declared in <signal.h>, but POSIX
      requires this.

    * The definitions of atof(), strtod(), and stroul() require
      that HUGE_VAL, ULONG_MAX, and ERANGE be defined in <stdlib.h>,
      but the defintion of that header forbids this.

    * The typedef name size_t should not be overloaded to represent
      values of both the number of elements in an array and the
      size of objects.  We sympathise greatly with the attempt to
      avoid namespace pollution.  We understand that currently, the
      smallest object that can be an array element is 1 byte,
      and that, given this, it can be proved that size_t will
      always suffice for this purpose.  However, this overloading
      precludes future extensions such as bit field arrays.

X/Open Kernel Technical Working Group
sun!sunuk!inset!xopen!XoTGKern
XoTGKern at xopen.co.uk