generic intrinsic function names

David Hough uunet!Eng.Sun.COM!David.Hough
Mon Oct 21 12:09:23 PDT 1991


Rex raises a good point which I didn't include as a specific rationale
section.   My intent is that by taking some appropriate step, the programmer
may use the familiar names for generic functions without changing any
of his code except header file inclusions.

There are several possible ways of doing this.  I don't like the idea
of changing math.h which is complicated enough as it is already, when
properly ifdef'd to support ANSI-C, SVID, X/Open, POSIX, etc.

We could either

	define a new header to include immediately after math.h
or
	define a new header to replace math.h

I mentioned both possibilities in the first draft but didn't get any
responses one way or the other, so I went with plan A.
Plan B requires including definitions in the new header
for all the things in math.h that
we don't intend to change, and so seemed less desirable..
Or the new header file could be defined to 
	#include <math.h>
followed by all the undef-define pairs, but I don't recall that any
other ANSI-C headers is defined recursively..
I don't have strong feelings among these approaches.

> DEC's VAX C V3.x added intrinsics for builtin VAX instructions just
> like this.  In their case, some of the trailing arguments were optional in
> which case each intrinsic had a number of prototypes for the possible
> combinations.

This is the sort of problem that I don't want to attack - too general a 
solution in C - leave those for C++.  The only "varargs" generic functions
I proposed are flavors of min and max, and those could be fixed at two
arguments without much loss of convenience if that would help implementations
significantly.



More information about the Numeric-interest mailing list