summaryrefslogtreecommitdiff
path: root/include/stdio.h (follow)
AgeCommit message (Collapse)Author
2024-10-10Disable snprintf/sprintf hardening for now2.3.2jvoisin
2024-09-06Work around a gcc warningjvoisin
It seems that annotating sprintf with `write` makes gcc unhappy, as its analyser is unable to understand that we're checking if `__b != -1` before calling `__orig_snprintf`, so let's comment this annotation for now.
2024-07-10Fix access annotations to snprintf/sprintfjvoisin
In the same spirit as the previous commit. Reported-by: ncopa
2024-07-10Fix `access` annotations for vsnprintf/vsprintfjvoisin
This fix the following issue: ``` In file included from exec-cmd.c:9: In function 'vsnprintf', inlined from 'report.constprop' at subcmd-util.h:13:2: /usr/include/fortify/stdio.h:162:16: error: 'msg' may be used uninitialized [-Werror=maybe-uninitialized] 162 | return __orig_vsnprintf(__s, __n, __f, __v); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/fortify/strings.h:23, from /usr/include/string.h:59, from /usr/include/fortify/string.h:23, from /home/ncopa/aports/main/linux-lts/src/linux-6.6/tools/include/linux/string.h:6, from exec-cmd.c:3: /usr/include/fortify/stdio.h: In function 'report.constprop': /usr/include/fortify/stdio.h:152:1: note: in a call to '__orig_vsnprintf' declared with attribute 'access (read_write, 1, 2)' here 152 | _FORTIFY_FN(vsnprintf) int vsnprintf(char * _FORTIFY_POS0 __s, size_t __n, | ^~~~~~~~~~~ In file included from exec-cmd.c:10: subcmd-util.h:12:14: note: 'msg' declared here 12 | char msg[1024]; | ^~~ cc1: all warnings being treated as errors make[5]: *** [/home/ncopa/aports/main/linux-lts/src/linux-6.6/tools/build/Makefile.build:98: /home/ncopa/aports/main/linux-lts/src/build-virt.x86_64/tools/objtool/libsubcmd/exec-cmd.o] Error 1 make[4]: *** [Makefile:80: /home/ncopa/aports/main/linux-lts/src/build-virt.x86_64/tools/objtool/libsubcmd/libsubcmd-in.o] Error 2 make[3]: *** [Makefile:78: /home/ncopa/aports/main/linux-lts/src/build-virt.x86_64/tools/objtool/libsubcmd/libsubcmd.a] Error 2 make[2]: *** [Makefile:73: objtool] Error 2 make[1]: *** [/home/ncopa/aports/main/linux-lts/src/linux-6.6/Makefile:1362: tools/objtool] Error 2 make: *** [/home/ncopa/aports/main/linux-lts/src/linux-6.6/Makefile:234: __sub-make] Error 2 ``` Reported-by: ncopa
2024-07-10prefix special defines with FORTIFY_psykose
just in case, and because 'PEDANTIC_CHECKS' is a really generic name
2024-06-14Remove `restrict` keywordsjvoisin
- They're not used anywhere else in fortify-headers - It's breaking compilation on C++, because compatibility is hard It was initially reported on https://gitlab.alpinelinux.org/alpine/aports/-/issues/16200
2024-05-26Add vasprintf/asprintf2.3jvoisin
The only hardening being done here is to set the char** parameter to thos functions to NULL in case of an error, to prevent it from being used should people forget to check return values. This is already done on some BSD, as well as in Rocky Linux.
2023-12-15Rename some macros to be more namespace-friendlyq66
2023-12-15Guard some conditional stdio APIs with the right macrosq66
Fixes https://github.com/jvoisin/fortify-headers/issues/34
2023-12-15Remove superfluous includesjvoisin
This should fix #32
2023-12-06Work around an erroneous `-Wformat-nonliteral` bug in gccjvoisin
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110834 Reported-by: ksperling-apple
2023-10-01Add vfprintf`jvoisin
2023-10-01Add `fprintf`jvoisin
2023-09-30Add `vprintf`jvoisin
2023-09-29Make use of the native _chk variants for realjvoisin
2023-09-28Add `printf` hardeningjvoisin
2023-09-27Add support for more builtin compiler provided _chk variantsjvoisin
2023-09-27Add an option to make use of compiler-provided _chk builtinsjvoisin
2023-09-22Add more __diagnose_as_builtin annotationsjvoisin
2023-09-21Properly enable diagnose_as_builtin attributejvoisin
2023-08-22Clean up some includesjvoisin
- Remove a superfluous `#if defined(__has_builtin)` since it's already accounted for in include/fortify-headers.h - Replace `_FORTIFY_FD_POS0` with the already existing `_FORTIFY_POS0` - Factorise some duplicate code into a macro
2023-08-20Add more __access annotations in stdio.hjvoisin
2023-08-20Add two __format annotationsjvoisin
2023-08-20Make use of __diagnose_as_builtinjvoisin
2023-08-20Fix clang buildjvoisin
- s/CLFAGS/CFLAGS/ - provide paths to local includes - sprinkle more __pass_object_size__ - remove a problematic test
2023-07-09Add some malloc annotationsjvoisin
2023-07-09Add some `format` annotationsjvoisin
2023-07-09Improve a bit `size_t*size_t` overflow checksjvoisin
2023-06-27Add more access-annotationsjvoisin
2023-06-25add initial clang supportDaniel Kolesa
2023-06-25avoid __extension__ with clangDaniel Kolesa
It seems useless and triggers 'error: expected external declaration'
2023-06-22Add an annotation for fgetsjvoisin
2023-04-13Make use of __builtin_dynamic_object_sizejvoisin
GCC and Clang provide __builtin_dynamic_object_size (see documentation: https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html), so we should make use of it when its available.
2018-07-24Don't use __extension__ in C++ codeA. Wilcox
A few important notes: * __extension__ is a GNU C "alternate" keyword, not a C++ keyword.[1] * __extension__ is designed to work on "expressions"; it does work on #include_next in C mode, but it has no effect in C++ mode; the warning will still appear, if enabled, even with __extension__ preceding #include_next. This is because #include_next is not considered an expression in C++, so the compiler attaches __extension__ to the first expression of the header. All of this leads us to a build failure while building at least all Mozilla software. Moz has an alternate -isystem dir searched before /usr/include that overrides some headers, including <features.h>. The first statement in each of these headers is a #pragma, and since __extension__ is looking for an expression, and #pragma is a "null" expression, we end up with the following error: dist/system_wrappers/features.h:1:9: error: '#pragma' is not allowed here Since __extension__ has no effect on #include_next in C++ mode anyway, and since it can cause breakage, this commit omits __extension__ in C++ mode. [1]: https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/Alternate-Keywords.html
2016-09-10Bump copyright yearsin
2015-06-25Add __extension__ mark to include_next to silence -pedanticSteven Barth
Signed-off-by: Steven Barth <steven@midlink.org>
2015-06-03Use namespace-safe macro, param and variable namesTrutz Behn
2015-05-13Add LICENSE headersin
2015-05-13Add fortify_fn() helper in fortify-headers.hsin
2015-03-14Use __typeof__ to in part avoid replicating function typesTrutz Behn
2015-03-14Fix typo in attribute nameTrutz Behn
2015-03-14Add __artificial__ to aid in debuggingsin
2015-03-13Restore C++ supportsin
2015-03-13Implement snprintf() and sprintf() using __builtin_va_arg_pack()sin
Requires at least GCC 4.3.
2015-03-13Re-order vsnprintf() and vsprintf()sin
vsprintf() needs to access __vsnprintf_orig().
2015-03-13Fix typosin
2015-03-13Rework fortify implementation to use extern inlinesin
Overriding functions with macros is legal in C but a lot of software is not prepared for it. Use the extern inline method to achieve the same result.
2015-03-11Put include guards in the reserved namespaceTrutz Behn
fortify-headers is considered part of the implementation.
2015-03-11Ignore C++ for nowsin
It is not legal to override standard functions using macros in C++. We may have to revisit this in the future.
2015-03-11Add ifdef guards for C++ codesin