C Builtin Funxions

[root]

Doug Gwyn responds:
> In article <2524 at brl-smoke.ARPA> rbj at icst-cmr (root) writes:
> >Before I flame at the bogosity of this proposed madness, I will entertain
> >suggestions as to why this decision was made. Fire away.
> >
> >However, most builtin funxions will accept user redefinitions. Will this
					^^^^^^^^^^^^^^^^^^^^^^^^
> >be allowed, or must we resort to #defines to avoid hacking up the
> >sources to change every funxion we wish to redefine. And will this even
> >work? It's conceivable that the preprocessor could be integrated with
> >the compiler proper and not a separate pass/program in some implementations.
> 
> In a hosted (ONLY) implementation, some library functions
> are likely to call on other library functions; if you
> redefine library functions yourself, you may well break
> other apparently unrelated library functions.  The only
> relatively safe redefinition would be one with a standard-
> conforming interface, but then why not just use the one
> provided?
> 
> In a free-standing implementation, of course, you can
> define all your own functions similar to those provided
> in a hosted environment.

Some of us know what we're doing. One sees lots of redefinitions of
things like `putc' in {VM,}UNIX code. It is often desirable to use
high level funxions (printf) while hacking up a lower level one.

While I can appreciate any `help' the compiler/optimizer might
offer (converting strcpy's, etc) I damn well demand the ability
to force redefinitions of library funxions if I so choose.

Interesting! We used to have sed scripts to convert our strcpy's
to efficient instruxions. In the future we may have script to
go the other way to undo the optimization!

	(Root Boy) Jim Cottrell		<rbj at cmr>