[cfe-dev] RFC: do not optimize on basis of __attribute__((nonnull)) in glibc headers

[Aaron Ballman via cfe-dev]

On Wed, Jan 4, 2017 at 12:43 PM, James Y Knight <jyknight at google.com> wrote:
> On Wed, Jan 4, 2017 at 11:12 AM, Aaron Ballman via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>>
>> So I would be opposed to ignoring those attributes in
>>
>> Sema (I think we should still warn when users do nonportable things),
>> but in favor of not changing the optimizer to capitalize on this
>> "opportunity."
>
>
> I'd be opposed to ignoring the attributes only in some places and not in
> others. It should be ignored totally, as if it wasn't present on those
> functions. Doing anything else sends the wrong message -- that libc authors
> should continue to use nonnull on these functions because they might be
> helpful, and won't do anything bad.
>
> But that should not be the message. The message to libc authors should be
> straightforward: please remove nonnull from these functions, because it's
> wrong.

I empathize with your message, but I disagree. Libc authors are not
wrong; they're conforming to the standard. Even if we're able to
convince WG14 that the standard is wrong, that won't impact practice
for years to come. Failing to warn users about non-portable behavior
is also a hostile way to treat users; I feel strongly that we should
continue to warn users when possible even if we ignore the attributes
due to dangerous optimizations.

~Aaron

> E.g.
> "Yes, the standard currently says you can't call e.g. memcpy(NULL, NULL, 0),
> but -- real user programs DO, and always have depended on being able to do
> so. And your library implementation is even careful to support that in its
> definitions of the functions. So, you should not tell the compiler that NULL
> is forbidden, because it would use that information to *mis*optimize
> people's code that is using the effectively-universal extension to the
> standard of allowing NULL with a zero length. In order to avoid breaking
> code before fixed headers are deployed everywhere, Clang has added a hack to
> ignore the nonnull attribute on these functions, but we'd like to be able to
> remove that hack in the future."