On Dec 3, 2014 12:57 AM, "Clemens Ladisch" <clem...@ladisch.de> wrote: > > James K. Lowden wrote: > > /* Copy N bytes of SRC to DEST. */ > > extern void *memcpy (void *__restrict __dest, > > __const void *__restrict __src, size_t __n) > > __THROW __nonnull ((1, 2)); > > > > IIUC the declaration specifies the pointer cannot be NULL and the > > compiler generates a diagnostic if it notices that it can be. But the > > declaration is strictly stricter than the standard defines. > > Do you have a standard that allows NULL? The one I quoted does not.
*The* standard is completely silent on passing NULL to memcpy or memset (other than dereference of NULL is undefined behavior). With a size of 0 there will never be a dereference. The library in use is trying to warn you about potential errors but in this case isn't smart enough to detect the 0 size value. I can appreciate why the "extra" cautious warning exists given how often error checking is ignored, but since the ubsan infrastructure works by instrumenting the code, an assert would arguably be a better approach that would be smart enough to detect more than the non null attribute is capable of. That doesn't help the current mistaken impression that there was a problem with SQLite that didn't really exist. Which is moot since DRH already worked around the "broken" warning. :) _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
