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 |
236
236
|[`-fhardened`](#-fhardened)| GCC 14.0.0 | Enable pre-determined set of hardening options in GCC |
237
237
|[`-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 |
238
+
|[`-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 |
238
239
239
240
[^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.
240
241
@@ -1154,6 +1155,25 @@ In rare cases applications may link to libraries solely for the purpose of runni
1154
1155
1155
1156
---
1156
1157
1158
+
### 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 |
1163
+
| <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 |
1164
+
1165
+
#### Synopsis
1166
+
1167
+
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.
1168
+
1169
+
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.
1170
+
1171
+
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.
1172
+
1173
+
[^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.
1174
+
1175
+
---
1176
+
1157
1177
## Discouraged Compiler Options
1158
1178
1159
1179
This section describes discouraged compiler and linker option flags that may lead to potential defects with security implications in produced binaries.
0 commit comments