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

[Hal Finkel via cfe-dev]

On 01/04/2017 11:43 AM, James Y Knight via cfe-dev wrote:
> On Wed, Jan 4, 2017 at 11:12 AM, Aaron Ballman via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto: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.

I think that we have a responsibility to our users to continue to warn 
(statically, in ubsan, etc.) on non-portable behavior, which this is and 
will continue to be in practice for at least a decade or two, regardless 
of the message we'd like to send libc authors. We cannot undo history 
here and this will be relevant to production systems for at least a 
decade. We can talk to libc developers directly -- they're a much 
smaller set -- and we can pursue change at the standards level while 
still providing the most useful set of tools to our users in the mean time.

  -Hal

>
> 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.
>
> 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."
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

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