On Sat, Oct 16, 2010 at 02:41:33PM +0300, Vladimir Kirillov wrote:
> Hi, Ingo!
>
> On 02:06 Fri 15 Oct, Ingo Schwarze wrote:
> > > so here's a diff to actually do pass a singly-malloced buffer
> > > to the caller who should free it manually.
> >
> > No, wait, you can't change the calling convention of an existing
> > library function just like that. That would turn all application
> > code which is now correct into a horrible bunch of memory leaks,
> > and all application code written for the new convention would
> > result in double frees when linked against old libraries.
>
> Right.
>
> > > It is good to subsequently replace all static stuff in libc, right?
> >
> > Not quite.
> > Instead, some people double the number of libc functions by
> > adding thread-safe versions, like in ctime() -> ctime() and ctime_r(),
> > and that is ugly enough.
> > I'm pretty sure you must not change how existing functions work.
>
> My primary goal of this is having a thread libc and a set of functions
> in it to be safely used by daemons (getmntinfo(3) is used at least by
> amd, mountd and snmpd) with controlled memory usage.
>
> I've seen internal libc mutexes to protect usage of shared data in some
> places, however they are likely to be stubs, right?
No, in a threaded environent, the locking primitives used by e.g.
malloc(3) are real.
>
> So, functions like getmntinfo() should be either internally protected or
> provided a second "*_r" implementation.
>
> Which method is the most preferred by the project?
You forget a third way of dealing with this: document that the function
returns static data and let the user of the API deal with it.
-Otto
