🚀 go-pugleaf

In article <827765484snz@tsys.demon.co.uk>,
Tom Wheeley  <tomw@tsys.demon.co.uk> wrote:

 >Surely you have just proved that the standard library is _not_ part of the
 >C language.  At the risk of seeming -pedantic, I would say that the standard
 >library is a part of the _standard C *implementation*_, but not a part of
 >the standard C *language*.
 >
 >That is why you can build the standard library within C -- you cannot write
 >the entire standard library using the standard library, therefore if the
 >standard library is a part of the C language, then the standard library is
 >no longer written in the C language, but only a limited subset thereof.

No, you would use somewhat of a superset: you would require special glue to
interface to the environment, otherwise you could not do I/O or dynamic memory
allocation. These methods are not defined by the C language. Of course, you
could use some standard library functions to build others, or even to define
themselves. 

What you are missing is that in _building_ the standard C implementation, one
does not follow the same rules that go into _using_ ANSI C. Some of the steps
in constructing the environment are not steps that are legal for the user of a
hosted C implementation.

In constructing the environment, I could have a special rule that would allow
me to do this:

int strcmp(const char *s1, const char *s2)

{
	return strcmp(s1, s2);
}

Where the internal strcmp() is assumed to be the special operator (whose
unconditional translation I could theoretically turn on with a special flag in
my compiler---not that this is how it's actually done!).

Of course, the above is not possible from the point of view of the user,
because it is tantamount to an external redefinition of a standard defined
function.

The user of the library would have the inlined operator strcmp(), and could
take the address of the above function version when needed (e.g. for passing
a pointer to the comparison function to a sorting routine).
--