<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 7:53 PM, Emmanuel Dreyfus <span dir="ltr"><<a href="mailto:manu@netbsd.org" target="_blank">manu@netbsd.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Vijay Bellur <<a href="mailto:vbellur@redhat.com">vbellur@redhat.com</a>> wrote:<br>
<br>
> There are a lot of places where we make an implicit assumption that<br>
> GF_CALLOC and the likes memset the memory area to zero.<br>
<br>
</div>The problem I refer to is that on current Linux systems,<br>
pthread_mutex_lock() will work on a zero'ed area where<br>
pthread_mutex_init() was not called. That behavior should not be taken<br>
for granted in the future on Linux, and it is likely to break on any non<br>
Linux system.<br></blockquote><div><br></div><div style>Right. What Vijay said is that GF_CALLOC is the wrong place to initialize memory with magic values, as it is _expected_ to strictly zero-fill the allocated buffer just like calloc(). Detecting a missed pthread_mutex_init of a mutex within a calloc'ed structure requires a more complex technique.</div>
<div style><br></div><div style>Avati</div><div style><br></div></div></div></div>