[clang] Add option -fstdlib-hardening= (PR #78763)

[Konstantin Varlamov via cfe-commits]

var-const wrote:

> I think that may depend on your background. For example, in the C standard library, there's a whole pile of `WANT` macros that users are expected to define before including a header file

Thanks, this is pretty interesting, and it's true that for users coming from that world setting a macro would probably feel quite natural. However, I generally find that the conventions of the C standard library are noticeably different from the C++ standard library, and many things that are common and normal in the C world feel unusual and sometimes inelegant. In my experience, many users feel that manually setting a macro is "hacky", doubly so if that macro has an internal name. They might also feel that they're fiddling with implementation details that might change in the future -- which wouldn't be true in this case, but IMO it still creates a certain barrier for adoption, perhaps pretty minor but still not negligible.

I personally think we absolutely should strive to add the `-fhardened` flag in a future LLVM release with semantics broadly compatible with those of GCC. However, we also need a separate way to control how hardening is enabled in libc++. For one, the `-fhardened` flag doesn't support the granularity (it can't e.g. distinguish between the fast and the extensive mode in libc++), and also it's possible that a project might want to e.g. enable hardening in the library but not to set some of the compiler flags that are part of `-fhardened` (I understand it's possible to opt out, but it feels inelegant and adds more friction).

That leaves us with essentially two options: a compiler flag or a "user-facing" macro. We feel a compiler flag is preferable for several closely related reasons:
- for many users, passing a macro definition manually feels "hacky" or "ugly". Unfortunately, even though it seems like a small and subjective thing, it will cause a barrier for adoption. Some users would feel that they are fiddling with the internal details of the library which might change without notice (not true in this case, but it's an additional burden on documentation/etc.). Some users would feel that having to set an internal macro indicates that this is an unpolished, unfinished feature that is not ready for production. Some users are not very comfortable with C++ and some of its older ways of doing things. To all of them, a flag would be preferable even if the effects were exactly the same.
- a flag can provide better diagnostics upon misuse. E.g. I would expect that if a user passes an incorrect mode name, the compiler invocation would fail immediately if a flag is being used, whereas otherwise it would be a compilation error coming from deep within the libc++ implementation, intermixed with other compilation output and potentially duplicated several times. Also, IIUC, the compiler would reject an unknown flag but I'm not sure we can catch setting an incorrect macro.
- a flag is documented in a uniform way (without users having to look for libc++-specific documentation to get even a basic idea of what each mode does);
- like Louis mentioned, as C++ adopts modules, macros feel increasingly outdated;
- having a flag is more future-proof in case we want to extend its effects beyond the current state. Otherwise users would have to update their build configuration (switch from setting a macro to setting the flag) to get the benefits;
- the fact that the flag boils down to setting a macro is an implementation detail that most users shouldn't need to worry (or know) about. In fact, we originally considered to set a feature instead (IIUC, we decided to go with the macro to make it compatible with GCC but I'm fuzzy on the details).


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