warnings in libbb.h

[Rob Landley]

On Monday 12 September 2005 03:31, Bernhard Fischer wrote:

> >> My dmalloc undef's those before it defines them. Also, it is
> >> recommended that dmalloc should be included last. Would the attached
> >> patch be appropriate (slightly tested with allyesconfig and both malloc
> >> and alloc on stack)?
> >
> >I don't seem to have a dmalloc.h anywhere on my system (ubuntu
> > "hoar-infested hedgehog" release.  Hey, I finally upgraded from knoppix
> > 3.6... :)  What's it for?
>
> It's a memory debugging library. see dmalloc.com
>
> I'll ask mjn3 to apply the patch as he seems to have been the last one
> who did touch dmalloc support.

Ah, I don't have that library installed, and have no idea if busybox actually 
still works with it or not.  (I'm assuming it did at one point...)

> >> //#warning yuk!
> >> char *fgets_str(FILE *file, const char *terminating_string);
> >
> >Compare to bb_get_line_from_file()...
>
> Only dpkg uses fgets_str(), perhaps i'll get to proposing a patch to
> remove fgets_str().

Be my guest.

We need more regression tests.  I'm working on that... :)

> >Do we really need libbb.h to #include standard headers for the applets? 
> > This isn't something busybox defines, I don't know why we have a
> > prototype for it at all...
>
> The prototype is probably there because of basename() as you say.
>
> I have no *real* opinion on whether or not libbb.h should #include
> headers it doesn't strictly need (I'd remove them and add them where
> they are actually needed, ymmv).

Well, in the case of something tricky like dirname/basename, localizing the 
knowledge to where it's actually used sounds good to me, rather than trying 
to have one #include file try to get it right for everybody...

> >A) I think those are translated messages.  What's the deal with this
> > #ifdef L_ stuff, anyway?  (Is this automatically generated by the
> > dependency stuff?)
>
> Well, it's currently not created by the dependency stuff (see the note
> below referring to vodz' new bb_mkdep)
>
> A c file contains several functions. These are #ifdef L_functionname.
> If a .config needs a certain function, it will (not now but hopefully
> later on, vodz) depend on it. The compiler will see the libs rule which
> says that for
> func.o: big.c
>  cc -DL_$(notdir $*) -c big.c -o func.o
>
> the "$(notdir $*)" is a long variant of "$(*F)", i.e. the filename of
> the stem. This expands to the final
> cc -DL_func -c big.c -o func.o
>
> With this approach, we would not need to build all and every objs
> provided by the libs only to discard it in the final (static) link
> stage of the busybox binary if it isn't referenced.
>
> I asked vodz what he thinks about also scanning for the functions
> provided by e.g. libbb.h when building the dependency-list with his new
> bb_mkdep. With these dependencies, it would no longer be necessary to build
> a ton of stuff when it's not needed anyway. See e.g. make allnoconfig and
> all the libs which are built. That part about emitting dependencies of the
> helper lib's obj was just a suggestion and would be a nice feature, imho.

I find this work cool, and am all for it, but am largely staying out of it on 
the theory that "looks good to me" in this context really doesn't mean much.  
(I.E. I hestiate to endorse something I'm not comfortable that I fully 
understand.  I'm generally following along, but if there was anything broken 
I'm unlikely to catch them.)

The best thing I could do here is add more tests to the test suite.  I 
mentioned an idea for an iterative build environment that tries each symbol 
separately.  Not full combinatorial coverage but simply starting with 
allnoconfig and looping through each symbol to switch it on, make oldconfig, 
build all, and make sure the build doesn't break.  (Maybe collect the "make 
sizes" for each one of those...)  Then the same for "allyesconfig" switching 
each symbol off...

Testing the dependencies would be a case of trying it with a "make clean" 
between each step and keeping all the binaries, and then trying it _without_ 
the make clean and checking to make sure the binaries produced were 
identical.

> >B) Compare mtab_file.c.
> >
> >I've avoided opening the "libbb cleanup" can of worms so far because,
> > well, it's big...
>
> Yes. I was thinking about gradual small steps for a start.
>
> We can easily put those two defines in a separate file (console.c to be
> unimaginative), ok?

I tend to have a tropism for _fewer_ files, just because I find it harder to 
keep track of stuff when dealing with lots of little files at once.  (Above a 
certain size source files get unwieldy, but _below_ a certain size you spend 
all your time switching between them and have too many open windows to keep 
track of.)

One reason I asked about the L_ defines was to see if that mechanism was 
usable for potentially consolidating some of the things in the libbb 
directory...

Rob