decot@hpisod2.HP.COM (Dave Decot) (04/12/88)
This is also posted to comp.lang.c, but because this 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@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@xopen.co.ukdecot@hpisod2.HP.COM (Dave Decot) (04/12/88)
I should mention that these comments are based on the draft of January 11, 1988 the most current draft available to the group at the time we met during the week of March 21. If some of these have been resolved by subsequent drafts, please don't flame us too badly. Dave Decot, Chair X/Open Kernel Group