No generic intrinsic functions in ANSI-C

[uunet!att!attunix!dfp]

David Hough summarized:

>I got four responses to my questions on this topic about a month ago.
>There was some disagreement about a number of details which makes me
>uneasy about advocating any implementation radically different
>from convention: the difference between "unconventional" and "nonstandard"
>may be commercially insignificant.  What is commercially significant is
>passing the validation suites of various third parties, and arguing with
>those parties about whether their validation tests correctly reflect a
>standard has never proven profitable in the past.  Sort of like turning
>in a paper in college that is more subtle or obscure
>than the reader is willing or able to deal with - it might as well be wrong. 
>
>Anyway here's some of my inquiries and conclusions so far:
>
>	A HOSTED ANSI-C compiler may treat the FUNCTION
>	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
>	EXTERNAL PROTOTYPE is in scope.
>
>This seems to be true, with the capitalized portions properly understood.
>HOSTED environments are optional as opposed to freestanding environments
>which have no reserved externals because those libraries may not have been
>compiled yet.
>FUNCTION identifiers
>excludes macro definitions and typedefs which also may appear
>in header files.
>EXTERNAL PROTOTYPE implies that local static function and other definitions
>can locally override the normally predefined library function identifiers.
>The presence or absence of e.g. #undef exp doesn't appear to affect the
>foregoing.

Not quite.  A program's behavior is undefined if the same name is declared
with both internal and external linkage in a translation unit.  Thus you can
have a local "sqrt" function, but only if <math.h> is not included by that
source file.

>The catch, however, is in the phrase "the specified semantics" particularly
>because of exception handling.
>
>So in the following, 
>assume a hosted environment and no local static definitions.
>
>	printf(" xyz ...", p1, p2, p3, ...) MUST 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.
>
>True, because printf is a defined standard library function.

False.  A compiler is not required to recognize any name as special, even in
a hosted implementation.  If an architecture uses a different calling sequence
when calling an explicit "..." function, it can require that an appropriate
declaration be visible at each call.  In particular, that means that the usual
minimal program:

	main(){
		printf("Hello, world\n");
	}

is not strictly conforming.  The strictly conforming version of this example is

	#include <stdio.h>
	main(){
		printf("Hello, world\n");
		return 0;
	}

> 	But if the varargs calling sequence is different from the normal one,
>	user-defined varargs functions
>	will not work unless a proper varargs prototype is in view at every
>	point where the function is invoked.
>
>True because user-defined varargs functions are not defined standard library
>functions.

The same can be true for library functions.

--

With respect to whether <math.h> functions can vary their precision based on
a call's argument types, I believe that the intent is to allow such and that
the standard does not preclude it.  (The only real question is in regards
errno's setting.)

Dave Prosser