<nmath.h> ? [forwarded for Rex Jaeschke]

[David Hough]

Rex's note is followed by more from dgh:

From: aussie!rexauunet.UU.NET (Rex Jaeschke)
Subject: Re: <nmath.h> ?

> Hough:
> In a mostly unrelated usenet posting, Doug Gwyn remarks in passing...
> 
> > My feeling is that the only
> > proper way to do that is through extensions of, not conflicts with,
> > the ANSI C standard.
> 
> It's clear to me at least that this particular solution is absolutely
> not what customers want.

I believe that Doug is expressing concern about the following section 
of the NCEG project proposal I drafted (and NCEG accepted last 
meeting) that was included in the recent X3J11/NCEG ballot.

	{3.1 Expected Relationship with X3, etc.}

	...

	The stated goal of NCEG is to be upwards compatible with ANSI~C. 
	However, it is conceded that in at least one area (namely error
	handling by certain library functions) NCEG may have to use an
	approach not sanctioned by ANSI~C.

Note that the key word here is "may". I was definitely NOT advocating 
we set out to "fix" or "break" ANSI C in this regard. However, I am 
told by more than a few knowledgable NCEG members that errno is a 
major thorn in their sides. Assuming NCEG is actually adopted as a 
working group within X3J11 (which appears likely) it is my job as 
convenor to monitor issues that are incompatible with existing 
standards. HOWEVER, NCEG's mission is to produce a technical report 
NOT a standard. Even if NCEG recommends an alternative error handling 
mechanism X3J11 is under no obligation to adopt it. In fact, I expect 
numerous NCEG efforts will result in implementation-defined or 
undefined behaviors due to conflicting prior art or failure to agree. 
That's OK too.

I REALLY want to make sure everyone (within and without NCEG) 
understands that I personally, am not at all advocating NCEG stray
from other than being a proper superset of ANSI C. Only the final 
analysis will show if that's in fact workable.

Rex

----------------------------------------------------------------------------
Rex Jaeschke     |  Journal of C Language Translation  | C Users Journal
(703) 860-0091   |        2051 Swans Neck Way          | DEC PROFESSIONAL
uunet!aussie!rex |     Reston, Virginia 22091, USA     | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------

============================================================================

dgh:

> errno is a
> major thorn in their sides 

More properly, a major thorn in their customers' sides.  For instance,
with Sun C (possibly GCC too), 
you can conform to the SVID (errno and matherr) if you use
libm.a plain, or you can compile your program with 68881 inline expansion
templates that don't bother.  I have never had a complaint about SVID
conformance with or without the templates, but numerous complaints 
about the necessity of using inline expansion templates to maximize
performance in numerical C programs.  These complaints often come from
people who have just completed substantial translation programs from
Fortran to C because "everybody knows that C is more efficient and
portable than Fortran" only to find that it ain't necessarily so.