<div dir="ltr">Why should memset / memcpy be attribute nonnull? Is there standardese that supports that?</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 1, 2015 at 7:20 AM, Marshall Clow <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This weekend, I got an email from Nuno Lopes informing me that UBSAN now paid attention to attribute(nonnull), and he was having some problems with it going off when using libc++.<div><br></div><div>I did some investigation, and found that he was exactly right - there were places (deep inside the vector code, for example) which called std::memcpy(null, null, 0) - which is definitely UB.</div><div><br></div><div>In an ideal world, our C library would define ::memcpy with the correct annotations, and libc++ would import that into namespace std, and we'd be golden. </div><div><br></div><div>But we don't have a C library - we use whatever is provided by the system we're running on, so that's not really an option.</div><div><br></div><div>For my testing, I changed libc++'s <cstring> header:</div><div><br></div><div><div>-using ::memcpy;</div><div>+inline _LIBCPP_INLINE_VISIBILITY </div><div>+void* memcpy(void* __s1, const void* __s2, size_t __n) __attribute__((nonnull(1, 2)))</div><div>+{ return ::memcpy(__s1, __s2, __n); }</div></div><div><br></div><div>(similarly for memmove and memcmp), and I found several cases of simple code that now UBSAN fires off on:</div><div><br></div><div>such as: std::vector<int> v; v.push_back(1);</div><div>and : int *p = NULL; std::copy(p,p,p);</div><div><br></div><div>This seems fairly useful to me.</div><div><br></div><div>I would like to hear other people's opinions about:</div><div><br></div><div>* Is adding this kind of UB detection something that people want in libc++?</div><div><br></div><div>* What do people think about wrapping the C library functions to enable UBSAN to catch them (this is a separate Q from the first Q, because I can see putting these kind of parameter checks into functions that have no counterpart in the C library). Sadly, this would NOT affect calls to ::memcpy (for example), just std::memcpy.</div><div><br></div><div>* Is that the best way to annotate the declarations? Is there a more portable, standard way to do this (things that start with double underscores worry me). In any case, I would probably wrap this in a macro to support compilers that don't understand whatever mechanism we end up using.</div><div><br></div><div>Thanks</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- Marshall</div><div><br></div></font></span></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>