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? So, functions like getmntinfo() should be either internally protected or provided a second "*_r" implementation. Which method is the most preferred by the project?
