You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|[`-fexceptions`](#-fexceptions)| GCC 2.95.3<br/>Clang 2.6.0 | Enable exception propagation to harden multi-threaded C code |
240
240
|[`-fhardened`](#-fhardened)| GCC 14.0.0 | Enable pre-determined set of hardening options in GCC |
241
241
|[`-Wl,--as-needed`](#-Wl,--as-needed)<br/>[`-Wl,--no-copy-dt-needed-entries`](#-Wl,--no-copy-dt-needed-entries)| Binutils 2.20.0 | Allow linker to omit libraries specified on the command line to link against if they are not used |
242
+
|[`-fzero-init-padding-bits=all`](#-fzero-init-padding-bits=all)| GCC 15.0.0 | Guarantee zero initialization of padding bits in all automatic variable initializers |
242
243
243
244
[^Guelton20]: The implementation of `-D_FORTIFY_SOURCE={1,2,3}` in the GNU libc (glibc) relies heavily on implementation details within GCC. Clang implements its own style of fortified function calls (originally introduced for Android’s bionic libc) but as of Clang / LLVM 14.0.6 incorrectly produces non-fortified calls to some glibc functions with `_FORTIFY_SOURCE` . Code set to be fortified with Clang will still compile, but may not always benefit from the fortified function variants in glibc. For more information see: Guelton, Serge, [Toward _FORTIFY_SOURCE parity between Clang and GCC. Red Hat Developer](https://developers.redhat.com/blog/2020/02/11/toward-_fortify_source-parity-between-clang-and-gcc), Red Hat Developer, 2020-02-11 and Poyarekar, Siddhesh, [D91677 Avoid simplification of library functions when callee has an implementation](https://reviews.llvm.org/D91677), LLVM Phabricator, 2020-11-17.
244
245
@@ -1168,6 +1169,25 @@ In rare cases applications may link to libraries solely for the purpose of runni
1168
1169
1169
1170
---
1170
1171
1172
+
### Guarantee zero initialization of padding bits in automatic variable initializers
| <span id="-fzero-init-padding-bits=all">`-fzero-init-padding-bits=all`</span> | GCC 15.0.0 | Guarantee zero initialization of padding bits in all automatic variable initializers |
1177
+
| <span id="-fzero-init-padding-bits=union">`-fzero-init-padding-bits=union`</span> | GCC 15.0.0 | Guarantee zero initialization of padding bits in unions on top of what the standards guarantee |
1178
+
1179
+
#### Synopsis
1180
+
1181
+
The `-fzero-init-padding-bits=all` option in GCC guarantees zero initialization of padding bits of structures and unions and reduces the risk that an incomplete initialization reveals sensitive information.
1182
+
1183
+
We recommend the use of `{}` initializers for unions as this is a standards-compliant way to zero-initialize a whole union, including its paddings bits, in the C23 and C++ standards. However, older code may use a different approach, some compilers may not support it, and developers sometimes make mistakes, so this option reduces the risk of such problems.
1184
+
1185
+
Since version 15, GCC adopted a stricter standards-compliant implementation of struct and union initializers.[^gcc-release-notes-15] Until GCC 14, `{0}` initializers would zero-initialize the whole union. With GCC 15 and later `{0}` initializer in C or C++ for unions no longer guarantees clearing of the whole union (except for static storage duration initialization). Only the first union member is initialized to zero. The `-fzero-init-padding-bits=unions` option in GCC 15 restores the old GCC behavior.
1186
+
1187
+
[^gcc-release-notes-15]: GCC team, [GCC 15 Release Series Changes, New Features, and Fixes](https://gcc.gnu.org/gcc-15/changes.html), 2025-05-30.
1188
+
1189
+
---
1190
+
1171
1191
## Discouraged Compiler Options
1172
1192
1173
1193
This section describes discouraged compiler and linker option flags that may lead to potential defects with security implications in produced binaries.
0 commit comments