[libcxx-commits] [libcxx] [libc++][hardening] Add an experimental function to log hardening errors (PR #149452)

[Nikolas Klauser via libcxx-commits]

================
@@ -0,0 +1,40 @@
+// -*- C++ -*-
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef _LIBCPP___LOG_HARDENING_FAILURE
+#define _LIBCPP___LOG_HARDENING_FAILURE
+
+#include <__config>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_HAS_EXPERIMENTAL_HARDENING_OBSERVE_SEMANTIC
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+// This function should never be called directly from the code -- it should only be called through the
+// `_LIBCPP_LOG_HARDENING_FAILURE` macro.
+_LIBCPP_EXPORTED_FROM_ABI void __log_hardening_failure(const char* __message) _NOEXCEPT;
----------------
philnik777 wrote:

> > if most system API calls (IMO unfortunately) only provide an unsized version
> 
> FWIW, I fully agree that null-terminated strings are an unfortunate design decision; I don't know if it made more sense back in the day, but it is definitely part of the legacy burden on C++ nowadays.

It is part of the legacy, but my complaint is more that there is still no choice to not use them in some circumstances (like here). This basically forces the use of null-terminated strings on any language that wants to interact with these APIs.



> > Going the other way, do we expect this to be so rarely called that it should be considered cold?
> 
> I don't have any objection to this -- logically, it should be. At the very least, it makes sense to me to prioritize performance of valid code (which will start applying to the previously invalid code as well once the bugs are fixed).

Yeah, I think this is a very reasonable stance here. I also noticed that `[[gnu::cold]]` is ignored if you have PGO: https://clang.llvm.org/docs/AttributeReference.html#cold.

> We don't have a precedent for it, however (or at least I couldn't find it with simple grepping). Do you think this patch warrants introducing a cold attribute (which would have to work with MSVC, etc.)?

I'm not sure what you mean. We don't support MSVC - only Clang and GCC, so we can use `[[__gnu__::__cold__]]` unconditionally. Actually, any compiler has to accept the attribute, so even if someone were to use MSVC somehow it has to be able to at least parse and ignore the attribute.


https://github.com/llvm/llvm-project/pull/149452