Re: Builtin bzero? Please don't.

[David Holland <dholland at eecs dot harvard dot edu>]

 > >    1. bzero() is not a standard function.
 > 
 > Neither is ffs, but we implement that one too.  Both are so common that
 > there's little risk of mistake.  Since we don't claim to be conforming
 > without -ansi, and that switch disables these non- standard functions,
 > we're correct.

Principle of least surprise?

I don't have a problem with putting something like
  
   #ifdef __GNUC__
   #define bzero __builtin_bzero
   #endif

or
   #ifdef __GNUC__
   #pragma builtin_bzero
   #endif

or whatever in <string.h>. What I'm objecting to is having all this
happen silently.

 > >    2. This transformation does not accomplish anything.
 > 
 > Yes it does.  Compilation proceeds through clear_storage, which, depending
 > on the size and alignment of the block and the capabilities of the target,
 > may result in the zeroing being expanded inline.

Ok, valid point. But...

 > >    3. Worse, this transformation is an anti-optimization.
 > 
 > memset with zero is so common that an implementation that doesn't special
 > case that for targets that have said mmu/cache features is severely lacking.

...you're still replacing a compile-time binding with a run-time test,
and that still looks like a pessimization to me. Perhaps there should
be a way to tell clear_storage to emit bzero calls instead of memset
calls?

In any event, please fix this:
   If you take the example code from the previous mail, and make the
   bzero prototype have a "const void *" first argument, which does
   not in any reasonable way match the builtin, it still interprets
   the bzero call as a call to the builtin.

-- 
   - David A. Holland             |    VINO project home page:
     dholland@eecs.harvard.edu    | http://www.eecs.harvard.edu/vino