ANSI-C library functions can be generic intrinsic operators?

[David Hough]

Enough people have said so that I am beginning to believe it's not only true
but reflects the intent of X3J11, so the question is, does anybody DISAGREE
with the following statement about ANSI-C compilers:

	An ANSI-C compiler may treat the identifiers defined in the Library
	Chapter 4 as reserved words having the specified semantics without
	regard to whether a function prototype or any other user-supplied
	definition is in scope.

If incorrect how should that statement be modified?  For instance, is the
following more correct:

	An ANSI-C compiler may treat the identifiers defined in the Library
	Chapter 4 as reserved words having the specified semantics without
	regard to whether a function prototype or any other user-supplied
	definition is in scope, as long as the identifier is not 
	explicitly #undef'd by the user code prior to use.

In particular, consider these cases:

	printf(" xyz ...", p1, p2, p3, ...) can be recognized by the compiler
	and the right thing done (for instance checking correspondence of
	parameters to formats) whether or not a prototype is in scope,
	even in the case where the varargs calling sequence is different
	from the normal one. (In that case user-defined varargs functions
	will not work unless a proper varargs prototype is in view at every
	point where the function is invoked).

	sqrt(expression) can be recognized by the compiler and appropriate
	code generated to return a value of the same type as the expression.

	what effect does #undef sqrt have on subsequent interpretation of
	"sqrt"?  It's intended to force a genuine function invocation, and
	is essential if a standard function is to be passed by a pointer
	since math.h may be written

		extern double sqrt(double);
		#define sqrt __generic_intrinsic_sqrt

Can sqrt(float) return a float?
Can sqrt(long double) return a long double?  Can sqrt(int) return an int?
This is somewhat at variance with the definition of functional definition
of sqrt as returning
a double.  You might not notice with float - that's how C got along for so
long with only double math.h functions - but you sure would notice with
int or long double arguments.  If the sqrt(long double) were like a generic
intrinsic operator then there would seem
to be no need for reserving sqrtf and sqrtl identifiers for future expansion.
Certainly sqrt(float) and sqrt(int) may produce double results by the usual
promotion rules to the double type of sqrt's parameter, but what about
sqrt(long double).  

The intent of X3J11 (if there was an agreed interpretation of these cases)
is as important as what the text of the standard says, particularly if the
latter is inconclusive or inconsistent.  The key to intent is whether a
request for interpretation now would generate an overwhelming consensus as to
the correct interpretation.