🚀 go-pugleaf

In article <3154A548.71FF@iadfw.net>, Larry Weiss  <lfw@iadfw.net> wrote:

>OK, now we are in sync.     I just wanted to know if anyone who used to
>do that sort of thing was upset with the implementations that choose to
>use inline techniques at code generation time for one or more standard
>library functions.

I would be very upset if the implementation did not allow me to turn it of,
like the -fno-builtin option of GCC. Sometimes it is very useful to write your
own malloc() (though I don't know of any implementation that inlines malloc()
calls).

>Looking at it another way, until the C Standard was published, I just looked
>at the vendor supplied library as a popular example of how one might go about
>interfacing with a file system, or manipluating strings, etc.   I didn't
>think of the library as a formal part of the C language.   Now, of course

Neither does the K&R2: this I think is a major flaw in the otherwise great
book. It never makes clear the concept that the standard library is a component
of the language. In fact, it claims the opposite:

	The standard library is not part of the C language proper, but an
	environment that supports standard C will provide the function
	declarations and type and macro definitions of this library.
	(beginning of Appendix B).

>the standard library is a well defined component of the C language, with
>the implementation able to know all sorts of things about the semantics of
>each library function.     C suddenly became much larger and complex with the
>publication of the Standard, in my mind.     It would have been nice if the

Not at all; that's the beauty of it! All of the standard library functions can
be implemented by essentially adding a compatible library and headers to a
``freestanding'' implementation. The standard doesn't _require_ that you inline
any of the functions or that the compiler be aware of special semantics, but
the implementor has the freedom to do this. This is why the inclusion of
appropriate headers is still required when you use standard functions---for
example, you must include <stdlib.h> to call malloc(), or <stdio.h> to use
printf().  If the compiler were really required to know malloc or printf a
priori, the need for a header file could easily have been dropped long ago.
--