gcc-poison alternatives and similar libraries
Based on the "Miscellaneous" category.
Alternatively, view gcc-poison alternatives based on common mentions on social networks and blogs.
-
ZXing
An open-source, multi-format 1D/2D barcode image processing library implemented in Java, with ports to other languages. [Apache] -
ZBar
A barcode scanner library, which allows to scan photos/images/video streams for barcodes and return their value. [LGPL2] -
American fuzzy lop
Crazy fuzzing tool that automatically discovers bugs given time and minimal example input. [Apache2] -
UNITS
a compile-time, header-only, dimensional analysis and unit conversion library built on c++14 with no dependencies. -
Better String
An alternative to the string library for C which is more functional and does not have buffer overflow overrun problems. Also includes a C++ wrapper. [BSD, GPL2] -
value-category-cheatsheet
A PDF cheatsheet for lvalues, rvalues, and the like. [Jank copyleft] -
CommonPP
Small library helping you with basic stuff like getting metrics out of your code, thread naming, etc.
Get performance insights in less than 4 minutes
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest. Visit our partner's website for more details.
Do you think we are missing an alternative of gcc-poison or a related project?
README
gcc-poison
gcc-poison is a simple header file for developers to ban unsafe C/C++ functions from applications. It uses the #pragma GCC poison directive to define a number of identifiers (function names) as unsafe. Compilation will fail if these are present in your code.
Please see http://blog.leafsr.com/2013/12/gcc-poison.html for more information
Example usage
#include <stdio.h>
#include <string.h>
#include "gcc-poison.h"
int main(int argc, char *argv[]) {
char buf[10];
strcpy(buf, argv[1]);
return 0;
}
$ gcc -o 2 2.c
1.c: In function ‘main’:
1.c:8:2: error: attempt to use poisoned "strcpy"
Excluding specific functions from poisoning
As pointed out in the GCC documentation (http://gcc.gnu.org/onlinedocs/cpp/Pragmas.html), "If a poisoned identifier appears as part of the expansion of a macro which was defined before the identifier was poisoned, it will not cause an error. This lets you poison an identifier without worrying about system headers defining macros that use it."
Here is an example of how to use gcc-poison.h but continue to allow the usage of the 'strcat' function, via a macro:
#define _unsafe_strcat strcat
#include "gcc-poison.h"
int main(void)
{
char x[512];
/* this will raise an error */
strcat((char *)&x, "lol");
/* ... while this will NOT raise an error */
_unsafe_strcat((char *)&x, "lol");
}
Note that you must define any such macros BEFORE you include gcc-poison.h. This can be a handy way to allow developers to continue to use certain functions for which libc has no safe alternative, while forcing them to acknowledge that they are doing so unsafely.