the truth about the LCAS <9104041542.AA06034afork-city.pa.dec.com>

[Donn Terry]

Martha Jaffe writes...

>1. First, it's the implementation, not the program, that conforms or not to
>the LCAS.

>2. It's true that, in order to conform to the LCAS, the implementation must
>provide a way of enabling the detection and reporting of integer overflows,
>integer divide-by-zeros, floating overflows, floating divide-by-zeros,
>and any other "invalid" or "undefined" floating point events.  This need
>not be the only mode of operation offered by the implementation, nor even 
>the default mode.  

>From this a read that LCAS does not specify the means whereby this is
controlled, leaving it to the implementation.  *If* I read that correctly,
this implies that any (non-trivially) LCAS conformant application (that
is, one that makes use of any implementation-defined means to control
arithmetic) is not a portable application.  (Is a "portable application
using extensions" at best.)

I hope I'm wrong.  However, if I am not, what is beng done to address the
issue.  (I suspect that NCEG is in a good place to address it, but what
about other languages?)

In general, adding "implementation-defined" interfaces is not particularly
useful toward creating portable applications.

Donn Terry


------- End of Forwarded Message