[cfe-dev] RFC: Nullability qualifiers

[Marshall Clow]

On Mar 2, 2015, at 1:22 PM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> Zero effect on ABI or code generation: There are a huge number of interfaces that could benefit from the use of nullability qualifiers, but we won’t get widespread adoption if introducing the nullability qualifiers means breaking existing code, either in the ABI (say, because nullability qualifiers are mangled into the type) or at execution time (e.g., because a non-null pointer ends up being null along some error path and causes undefined behavior).

I’m pretty sure that you know this, Doug, but:

gcc already does (some of) this kind of stuff, and they *absolutely* use it in their codegen decisions.

consider the following (simplified, fanciful) code:

char global[1000];

char *foo (char *p, size_t sz)
{
//	stash a copy away
	memcpy(global, p, sz);

	if (p == NULL)
		p = (char *) malloc(100);
	return p;
}

char *p2 = NULL;
char *p3 = foo(p2, 0);

After executing this code, what will the value of ‘p3’ be?
Under gcc/glibc, it will be NULL, because memcpy is marked with “non-null” attributes, and so the “if (p==NULL)” branch is removed.
(Yes, even though memcpy(x, y, 0) will not dereference the pointer)

— Marshall


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150305/db004abd/attachment.html>