lost message: the LCAS and C

[David G. Hough on validgh]

[The following may have been lost due to mailer problems while I was gone - dgh]

Date: Wed, 1 May 91 19:19:30 PDT
From: uunet!twinsun.com!eggert (Paul Eggert)
To: validgh!numeric-interest
Subject: the LCAS and C

With respect to C and IEEE floating point, the major problems with the
Language Compatible Arithmetic Standard (LCAS) are notification and
documentation of translation.  The first problem is the most severe, because
the LCAS is incompatible with the IEEE 754 default.


Notification.

The LCAS requires that an implementation either invoke an exception handler or
output a message whenever an operation returns an exceptional value.  It
explicitly rules out returning an exceptional value, even though this is in
widespread use, and is the default in IEEE 754 hosts.  This prohibition is a
serious mistake, and should be removed.  There is no hard evidence for the
apparent feeling of the LCAS committee that using exception handlers, rather
than exceptional values, will yield software that is more portable or
reliable.

To conform to both the LCAS, when an exceptional value is obtained an
implementation must either output a message, or must permit a signal handler
to do useful operations like outputting a message.  The former is relatively
useless to a programmer, and the LCAS itself recommends against it; the latter
has serious problems with ANSI C, which has severe restrictions on signal
handling that arise from real constraints on implementers and cannot be wished
away easily.

ANSI C's signal() mechanism does not satisfy the LCAS's requirement for
notification because a portable ANSI C signal handler can only set a global
variable, which does not constitute notification in the LCAS sense.
Therefore, in an ANSI C + LCAS environment, operations like printf() and
malloc() must be reentrant in the presence of signals.  An ANSI C + LCAS
standard would seemingly have to address issues such as behavior when an
exception handler raises another exception, or when the same expression raises
multiple exceptions.  It is quite possible that such a standard would prohibit
many useful optimizations.


Documentation of translation.

The LCAS requires standards and implementations documentation to specify ``the
translation of arithmetic expressions into combinations of operations provided
by'' the LCAS.

This statement seemingly requires a formal specification of optimizations
allowed by a standard and performed by an implementation.  However, apparently
only an loose, informal statement is required, along the lines of the example
in section C.5 of the LCAS.  The LCAS should explicitly permit an loose
statement of optimization strategies here.  Implementers are unlikely to
divulge all their optimization tricks even if the LCAS mandates disclosure.

This point becomes stronger when an implementation uses extended precision for
local variables.



Minor points.

The LCAS should recommend names for the `single' and `long double' versions of
`signf', `fabs', etc.

Section B.3 of the LCAS claims that `char' is always smaller than `int', but
the C standard does not support this claim, and permits `char' to be the same
size as `int'.  Several of the statements about `short int' have to be
modified, because it is possible that `char', `signed char', and `short int'
all conform to the LCAS.

The claim that ``small'' integer types cannot conform to the LCAS is
incorrect.  For example, if `x' and `y' are both of the small integer type
`short int', then an implementation's documentation could state that the
syntax for add[I] is `(short)(x + y)'.



Reference.

The First Committee Draft (Version 3.1) of the Language Compatible Arithmetic
Standard (LCAS) [JTC1.22.29, ``Information Technology -- Programming languages
-- Language compatible arithmetic,'' JTC1/SC22/WG11 N229, X3T2 91-073, ISO/IEC
10967:1991 (1 March 1991)] is available via anonymous FTP from crl.dec.com in
pub/misc/lcas.ps.