🚀 go-pugleaf

Peter Seebach wrote:
>  > In article <31545B86.4CC0@iadfw.net>, Larry Weiss  <lfw@iadfw.net> wrote:
 > >I don't understand.  Suppose that I want to substitute my strlen() logic
 > >for the vendors implementation of strlen() in such a way that not only
 > >my source's calls on strlen() are affected, but also any 3rd party's
 > >library's uses of strlen() get the "benefit".   How does your technique
 > >apply to that scenario?
 > 
 > It doesn't; this is arguably a feature, as this makes them immune to any
 > mistakes in my implementation of str_len().
 > 
 > If you have their source, you patch it.
 > 
 
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 sort of liked the simplicity of the implementations that did all standard
library calls with clearly replaceable external functions (and as far as I
can see, that technique is still allowed in an implementation), and at the
same time, I like the theoretical efficiency of the inlined approach.

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
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
library suite were given a more cohesive design, but I know that the Committee
did not want to break the majority of executing pre-Standard-C programs, so that
was off their agenda.