_FORTIFY_SOURCE=3 requires __builtin_dynamic_object_size. If the latter is not supported, the fortification level fallbacks to 2.
However, the user is misled by the ./configure script:
checking whether C++ preprocessor accepts -D_FORTIFY_SOURCE=3... yes
This PR avoids misleading the user.
Additionally, it prevents warnings like this:
warning: #warning Using _FORTIFY_SOURCE=2 (level 3 requires __builtin_dynamic_object_size support) [-Wcpp]
`_FORTIFY_SOURCE=3` requires `__builtin_dynamic_object_size`. If the
latter is not supported, the fortification level fallbacks to 2.
This change makes the selection of the fortification level explicit and
prevents warnings like this:
```
warning: #warning Using _FORTIFY_SOURCE=2 (level 3 requires __builtin_dynamic_object_size support) [-Wcpp]
```
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Concept NACK.
Concept NACK.
Mind elaborating?
The fallbacking works as intended on newer glibc, and setting three means we get 2 on any older glibc. No need to complicate this to "fix warnings", which iirc only appear for Windows in any case.
The fallbacking works as intended on newer glibc, and setting three means we get 2 on any older glibc.
It is hidden from the user who sees only
checking whether C++ preprocessor accepts -D_FORTIFY_SOURCE=3... yes
No need to complicate this to "fix warnings", which iirc only appear for Windows in any case.
"fix warnings" is just a byproduct of this change.
The main point is to provide the user with the truth about the fortification level which is actually supported and will be used during compilation.
<!--9cd9c72976c961c55c7acef8f6ba82cd-->
Concept NACK. This would break if someone had a (future?) compiler that supports 3 without that exact symbol.
If it really bothers you, maybe check for that specific warning in the output?
The main point is to provide the user with the truth about the fortification level which is actually supported and will be used during compilation.
I don't think this matters, or is something you can guarantee. IIRC, even in the case that the provided fortification level is supported, glibc may internally fallback to a lower level, for a certain function, depending on various tests. So in that case, even if 3 was supported by the compiler, a more complicated function may only get the hardening equivalent of 2.
We just want to attempt using the highest supported level in any case. No need to try and second-guess glibc, or essentially drag it's build machinery inside our own build system.