[PATCH] add a few new xfuns and use them as appropriate

[Bernhard Fischer]

On Fri, Apr 14, 2006 at 04:04:34PM -0400, Rob Landley wrote:
>On Friday 14 April 2006 4:57 am, Bernhard Fischer wrote:
>> >Would someone please explain to me why we need a bb_prefix on absolutely
>> >everything?  We don't have a bb_ prefix on xmalloc, I don't see why any of
>> >the x* needs a bb_ prefix.  Would someone please explain it to me?
>>
>> The xmalloc, xcalloc, xrealloc, xmemalign, xstrdup et al are special
>> since they may be replaced by their dmalloc_() implementations iff
>> building with dmalloc support.
>
>Ick.
>
>> We can of course name them with bb_ 
>> prefixes for consistent naming (which i tend to prefer, personally)
>
>I tend to view all the bb_ names as unnecessary clutter, myself...
>
>> and have them work with dmalloc nicely
>
>Ok, why does dmalloc get preferential treatment over valgrind, electric fence, 
>libmudflap, and the 8 gazillion other memory checking thingies out there?
>
>> , but current (not bb_ prefixed) seems to stem from there.

I said that it looks like the xmalloc name stems from mjn3's support for
dmalloc. dmalloc has no special treatment AFAICS. It could use special
treatment (it will abort on it's own so it's ok that our die() isn't
called), but currently doesn't have it.

>
>Actually, initially nothing had a bb_ prefix on it.  The first function with a 
>bb_ prefix was bb_regcomp() in svn 812, and then bb_setpwent() and friends in 
>1694.  Those names had the bb_ prefix because they conflicted with existing 
>names, which was an actual reason.  bb_asprintf() showed up in svn 5066 
>(again, conflicting with an existing name), and bb_vasprintf() in 5070.  
>bb_xgetlarg() showed up in 6173 as the first name that had a bb_ prefix 
>without directly conflicting with an existing name, and looking back on it 
>I'd say that name was a mistake.
>
>> All in all, whether we consistently prefix functions in libbb with bb_
>> to make their origin clear is a cosmetic question.
>
>True.
>
>> The majority of the internal library functions do have a bb_ prefix.
>
>How many still don't?

$ grep extern include/libbb.h | egrep -vi "(bb_|alloc)" | wc -l
57
$ grep extern include/libbb.h | egrep -i "(bb_|alloc)" | wc -l
108

This incomplete grep suggests that 108 do have a bb_ prefix while 57
don't have it.

>
>If bb_ signifies "lives in libbb" and we use that consistently, then it at 
>least serves a purpose.  I could live with bb_xmalloc() as long as we're 
>being consistent.

As said, i'd prefer consistency too, and the numbers suggest that
converting them all to be prefixed with bb_ is a sensible thing to do.

Is anyone strongly opposed to such a change, mid-term?