daver@hcx2.SSD.HARRIS.COM (05/10/89)
The pANS explains that the committee chose not to adopt System V's 'matherr' capability, and 'matherr' is not a reserved identifier. The 88open Trial Use OCS (3/10/89) lists 'matherr' as a service residing in libm (see section 7.4). Can an implementation, then, be both ANSI C and 88k OCS compliant in this regard? Or can both "standards" be satisfied by having a routine such as '__matherr'?
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/16/89)
In article <120200005@hcx2> daver@hcx2.SSD.HARRIS.COM writes: >The 88open Trial Use OCS (3/10/89) lists 'matherr' as a service residing in >libm (see section 7.4). >Can an implementation, then, be both ANSI C and 88k OCS compliant in this >regard? Or can both "standards" be satisfied by having a routine such as >'__matherr'? I don't know what the OCS says, but there is no injunction in the C Standard against an implementation providing additional functions in its C library, so long as no constraint of the Standard is thereby violated. The way this would have to be implemented would be for the math library functions to call __matherr() and for <math.h> to #define matherr __matherr as well as to declare struct exception. However, such definitions of reserved-for-application-use symbols must be controlled by some mechanism, e.g. #ifdef _POSIX_SOURCE, that ensures that the definitions will not occur when compiling in an ANSI-conforming mode. Vendors with IEEE floating-point architectures are already angry enough about having to mess around with errno; I can imagine what they must think about having to call matherr().