Previous: , Up: Brief Overview   [Contents][Index]


1.6 High Quality

We develop and maintain a testsuite for Gnulib. The goal is to have a 100% firm interface so that maintainers can feel free to update to the code in git at any time and know that their application will not break. This means that before any change can be committed to the repository, a test suite program must be produced that exposes the bug for regression testing. All experimental work should be done on branches to help promote this.

When compiling and testing Gnulib and Gnulib-using programs, certain compiler options can help improve reliability. The manywarnings module enables several forms of static checking in GCC and related compilers (see manywarnings). For dynamic checking, you can run configure with CFLAGS options appropriate for your compiler. For example:

./configure \
 CFLAGS='-g3 -O2'\
' -D_FORTIFY_SOURCE=2'\
' -fsanitize=undefined'\
' -fsanitize-undefined-trap-on-error'

Here:

Without the -fsanitize-undefined-trap-on-error option, -fsanitize=undefined causes messages to be printed, and execution continues after an undefined behavior situation. The message printing causes GCC-like compilers to arrange for the program to dynamically link to libraries it might not otherwise need. With GCC, instead of -fsanitize-undefined-trap-on-error you can use the -static-libubsan option to arrange for two of the extra libraries (libstdc++ and libubsan) to be linked statically rather than dynamically, though this typically bloats the executable and the remaining extra libraries are still linked dynamically.


Previous: Portability guidelines, Up: Brief Overview   [Contents][Index]