Radovan =?utf-8?q?Božić?= <[email protected]>, Radovan =?utf-8?q?Božić?= <[email protected]>, Radovan =?utf-8?q?Božić?= <[email protected]> Message-ID: In-Reply-To: <llvm.org/llvm/llvm-project/pull/[email protected]>
philnik777 wrote: > > @AaronBallman I don't think [#158626 > > (review)](https://github.com/llvm/llvm-project/pull/158626#pullrequestreview-3229443611) > > has really been addressed yet. > > Thanks for raising the concern! > > > If you think it's fine to basically undefine the behaviour of > > implementations that's fine with me, but I think we should acknowledge that > > we do that. > > The behavior is undefined according to the standard, so this is 1) ensuring > we get diagnostics for misuse, I'm 100% on board with this. It's most likely user error which should be diagnosed. However, this can be achieved by adding `_Nonnull` instead. That doesn't have any optimization implications as opposed to `[[gnu::nonnull]]`. > 2) improving optimization behavior. So it's not really the implementation > undefining the behavior, it's the implementation admitting the behavior was > already undefined (maybe too find of a distinction?). What I mean is that some libc implementations seem define their behaviour when a nullptr is passed. This is effectively undone by the compiler adding the `[[gnu::nonnull]]` and the actual libc has no say in this. For hardened implementations this is a very real issue, see e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121052. If this were to happen to a function libc++ defines I'd fight tooth and nail. > gcc seems to treat the parameters as being marked nonnull: > https://godbolt.org/z/YTb1ejh8W https://github.com/llvm/llvm-project/pull/160988 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
