🚀 go-pugleaf

In article <314DADD4.3DE@oc.com>, Larry Weiss  <lfw@oc.com> wrote:
 >Joachim Durchholz wrote:
 >
 > > There is one trait among many hackers that will make method gurus uneasy -
 > > they don't like to be restricted.
 > > This makes C popular among hackers - it gives many benefits of discipline
 > > (many opportunities for the compiler to do type checking), but allows
 > > evading the restrictions whenever necessary (type casts).
 >
 >
 >What do C hackers think about the new freedom (since the publication of
 >the C Standard) that compilers have to "inline" standard library calls,
 >thereby making it hard for hackers to provide their own variations of
 >any standard library "function" ?
 >
 >In the old days, when the Standard library was just another set of linkable
 >entry points, it was straightforward to replace the vendor's logic with
 >your own (maybe just the same with tracepoint logic, but maybe a very 
 >experimental replacement, and maybe a "better" one).   No more!

But you get the benefit of inlined, optimized memcpy() operations, and others!

 >What is the position of other languages with respect to their equivalent
 >of the "Standard library" ?   Can I hack the runtime support in other

In some languages, the ``standard library'' cannot even be _written_ in the
language. Try writing a Pascal function that is compatible with writeln(), for
instance. How could you do it when there is special syntax for specifying the
format for the arguments?

		writeln('Total: ', dollars:8:2);

 >languages today more easily than I can the C runtime?

Yes, because the standard makes a clear distinction between ``freestanding''
and ``hosted'' C environments.

In a freestanding implementation, most of the standard library functions are
not predefined. So there is still the sense of a language core that is free of
special operators.

In a hosted environment, you can still redefine a standard function, but the
definition must be restricted to static scope.

Many environments let you redefine the functions anyway.

Under GCC, the -fno-builtin option will turn off the special treatment of those
functions that are affected in that particular implementation. Most of the
library functions are always done through library calls; only a small subset is
inlined. From an outdated GCC man page, here is what you can glean:

      -fno-builtin
           Don't recognize built-in functions that do  not  begin  with  two
           leading  underscores.   Currently, the functions affected include
           _exit, abort, abs, alloca, cos, exit, fabs, labs, memcmp, memcpy,
           sin, sqrt, strcmp, strcpy, and strlen.

           The `-ansi' option prevents alloca and _exit from  being  builtin
           functions.

In GCC, this would be your ``escape hatch'', guaranteeing that every instance
of memcpy() will call for external linkage.

Any standard function that is not in the list is one you can redefine under
this implementation, and you can be confident that all your object files will
use the new function

The above are ones you wouldn't want to redefine anyway.  I doubt you could
make a better strcpy() or abs() than compiler-generated inline code! 
--