<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 14, 2015 at 7:12 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Apr 14, 2015, at 6:13 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
><br>
</span><span class="">> On Tue, Apr 14, 2015 at 6:00 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> > On Apr 14, 2015, at 5:40 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
> ><br>
> > Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
> >> I really do not want that. I am especially unwilling to do that just to<br>
> >> appease static analysis.<br>
> ><br>
> > I think it's actually better for debuggability and<br>
> > strictness/normalization within the code, but we had this argument a<br>
> > year ago and if you still insist, I'm not going to dig it up.<br>
><br>
>   But I did. So Matt's argument is that having a pointer you are not allowed to use be anything but NULL is dangerous because it could be used wrong and no one would know.<br>
><br>
>    BTW how come all the code  (!(m1) ? (*(r1) = 0,0) : 0)  stuff uses 0 instead of NULL? Wouldn't it be clearer to use NULL when one means NULL?<br>
><br>
</span>   I understand what you wrote below. My question is why there are a bunch of symbols 0 in the PetscMalloc() macros; shouldn't they be NULL for clarity.<br>
<br>
    0.0  for float, 0 for integer, and NULL for pointer?  That's all.</blockquote><div><br></div><div>I am fine for NULL. I was just using 0 since its equivalent and short.</div><div><br></div><div>  Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> I am arguing for uniformity. With the current system, all internal PETSc mallocs (we are supposed to use PetscMallocK everywhere)<br>
> will return NULL for 0 size argument. On the other hand, if you just forward the request to malloc, the standard says it can return<br>
> a valid pointer OR NULL, so now we have different behavior. What is worse is that this "valid" pointer can be freed, but it cannot<br>
> be dereferenced, and there is no way to determine that it cannot be dereferenced, unlike NULL. I see absolutely no good argument<br>
> for this situation.<br>
><br>
>    Matt<br>
><br>
><br>
>   Barry<br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>