[PATCH] Include netinet/in.h in libbb.h

[Rob Landley]

On Monday 05 June 2006 5:13 pm, Bernhard Fischer wrote:
> On Mon, Jun 05, 2006 at 01:19:51PM -0600, Shaun Jackman wrote:
> >On 6/5/06, Rob Landley <rob at landley.net> wrote:
> >>Query: Why are we supporting dmalloc again?  (Who uses it, and what for?
> >>What's the benefit?)
> >
> >It's useful for finding memory leaks and other heap abuses. I most
> >recently used it to track down the memory leak in ls.
>
> Yes, it's very handy.
>
> Rob, you moving the the #include <dmalloc.h> before the xmalloc
> prototype (r15287) is not ok (see comment in libbb.h for xmalloc).

Then it needs a _comment_ that it shouldn't be moved.  And we should move the 
specific protype(s) it needs before where it is now.

I'm fine with sequencing requirements, just not hidden or scattered sequencing 
requirements.

> We have to make sure to at least include the stdlib.h (where
> {m,c,re}alloc and free come from) before including dmalloc.h.
> Other candidates who should come before dmalloc.h is e.g. string.h
> and strings.h

Woot.

It's currently at the end of the #includes that we're doing in libbb.h.  We 
need to move #includes like strings.h into libbb.h from where they are in the 
individual applets.

> Also our xmalloc, xrealloc et. al. prototypes have to come *before* we
> include dmalloc.h, so it can override our impl (and abort).
>
> PS: http://dmalloc.com/docs/5.4.2/online/dmalloc_13.html#SEC13
> I'm using check-funcs on a regular basis for other stuff, and it really
> works best if you just make sure to have dmalloc.h as the last include.
> It's the least error-prone approach.

Ok.  I've advocated moving the other common #includes into libbb.h, this would 
support that. :)

Rob
-- 
Never bet against the cheap plastic solution.