gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] [PATCH 2/2] hacking: mention strdup in the no-malloc sect


From: Eric S. Raymond
Subject: Re: [gpsd-dev] [PATCH 2/2] hacking: mention strdup in the no-malloc section.
Date: Mon, 28 Mar 2016 08:28:40 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

Paul Fertser <address@hidden>:
> On Mon, Mar 28, 2016 at 12:18:58PM +0200, Beat Bolli wrote:
> >  <p>Don't undo this by using malloc/free in a driver or anywhere else.</p>
> >  
> > +<p>Please note that this restriction includes indirect callers of malloc
> > +like strdup.</p>
> > +
> 
> Strictly speaking, there's plenty of indirect malloc callers that are
> already used in gpsd. Early in the init sequence getservbyname() is
> called and it does malloc() under the hood. printf() implementations
> can also do that unpredicatbly, etc etc.

printf, at least does its own cleanup.  What we're trying to prevent
with this rule is resource leaks introduced by coding errors.

> One can say that the restriction applies to such library functions
> that require explicit free(). But what about
> initialize_dbus_connection()? It certainly does malloc() early on gpsd
> startup via dbus_bus_get(), and doesn't require explicit free().

No risk pf a resource leak here as it's called only once at init time.

To avoid having to pedabtically overspecify these edge cases we can say
that (a) if it requres a mabual free(), we don't use it, and (b) use of other
malloc callers is considered potentially harmful and has to be explicitly
approved during review.

> So the problem is not in the malloc/free but in the resource
> management in general. In C++ world you'd just require everybody to
> follow RAII. In the C world just prohibiting malloc/free is certainly
> not enough to tackle this, IMHO.

It's not *sufficient*, but it is *necessary*.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]