🚀 go-pugleaf

In article <31557321.6A8B@iadfw.net>, Larry Weiss  <lfw@iadfw.net> wrote:
 >Kazimir Kylheku wrote:
 > > 
 > > 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!
 > > --
 >
 >You may just want or need learn how many invocations of that logic occur.

 >Remember, I'm asking how does a hacker feel about the inability to depend on these
 >calls actually executing an easily replaceable or patchable code segment.
 >I suspect that a hacker would take your last sentence as a challenge, and
 >then if he/she were good enough, well who knows?
 >
 >I do understand the software engineer's needs (although even in that domain I
 >like to think that I can readily employ the memory leak-detector tools that rely on
 >not inlined malloc() free() code generation).    Although while wearing my

You should be able to. I don't think that malloc and free are commonly inlined.
Though if they are inlined in a library to which you don't have sources, you
are a poor soul. Library creators should watch out for this. I think that a
reasonable practice is to _not_ inline the functions when optimization is not
turned on. GCC behaves this way, in addition to providing an explicit switch.

Conscientious developers build two versions of a library.  For example, the
ncurses distribution will build a debugging version of the library as well as
an optimized production version. Even if malloc() were a builtin, I could count
on the GCC-compiled debugging library to actually use the call.

 >engineer's cap, if there were really good runtime efficiency gains to be had
 >by inlining those calls .... well it would be a tough decision.  (and the problem
 >there is with my 3rd party library code where the inline/not-inlined decisions
 >are already imposed, either helping or restricting my leak-detector.

Having only one version, with all the inline business in place is a big bummer.
Here is where the hacker as well as engineer in me would get pretty upset!

--