A header file that uses GCC's poison pragma to ban unsafe C/C++ functions from your codebase.
gcc-poison is a header file that uses GCC's `#pragma GCC poison` directive to ban unsafe C/C++ functions from applications. It helps developers prevent security vulnerabilities by making dangerous functions like `strcpy` or `gets` cause compilation errors. This forces teams to use safer alternatives or explicitly acknowledge unsafe usage through macros.
C and C++ developers working on security-sensitive applications who want to enforce safer coding practices at compile time. It's particularly useful for teams maintaining legacy codebases or building new projects with strict security requirements.
Developers choose gcc-poison because it provides a simple, zero-overhead way to catch unsafe code patterns early in the development cycle. Unlike runtime analysis tools, it integrates directly with the compiler and requires no additional dependencies or configuration.
gcc-poison
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
As a compile-time directive using #pragma GCC poison, it adds no performance penalty to the final binary, making it ideal for security-sensitive applications where efficiency is critical.
Just include the gcc-poison.h header in source files; no additional build steps or dependencies are required for GCC-based compilations, as shown in the example usage.
Allows defining macros before inclusion to permit specific unsafe functions, enabling controlled use while forcing acknowledgment, as demonstrated with strcat in the README.
Turns potential runtime vulnerabilities into compile-time errors, directly educating developers about dangerous functions like strcpy and encouraging safer alternatives.
Relies exclusively on GCC's #pragma GCC poison directive, making it incompatible with other compilers like MSVC or Clang without specific compatibility settings or extensions.
Only poisons specific function names; it fails to catch unsafe code patterns such as manual memory management errors, integer overflows, or misuse of allowed functions.
Primary reference is a blog post from 2013, and there's no indication of recent updates or active maintenance, which may lead to compatibility issues with modern toolchains.