Erik Auerswald
df0f1e35b7
GCC has become too aggressive with its warnings, complaining about more and more perfectly valid code. In August 2020 I received a report of GCC 10.1 generating a warning about strncat: --------8<-------- cc -D_FORTIFY_SOURCE=2 -Wall -W -Wextra -pedantic -Werror -pedantic-errors -fstack-protector-all -O3 -c -o ssocr.o ssocr.c In file included from /usr/include/string.h:495, from ssocr.c:29: In function ‘strncat’, inlined from ‘tmp_imgfile’ at ssocr.c:79:12, inlined from ‘main’ at ssocr.c:454:15: /usr/include/bits/string_fortified.h:136:10: error: ‘__builtin_strncat’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=] 136 | return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ssocr.c: In function ‘main’: ssocr.c:67:19: note: length computed here 67 | pattern_len = strlen(dir) + strlen(DIR_SEP TMP_FILE_PATTERN) + 1; | ^~~~~~~~~~~ cc1: all warnings being treated as errors make: *** [<builtin>: ssocr.o] Error 1 -------->8-------- Basically the same problem has been reported in GitHub issue #15, "Fails to build on Arm": --------8<-------- cc -D_FORTIFY_SOURCE=2 -Wall -W -Wextra -pedantic -Werror -pedantic-errors -fstack-protector-all -O3 -c -o ssocr.o ssocr.c In file included from /usr/include/string.h:495, from ssocr.c:29: In function ‘strncat’, inlined from ‘tmp_imgfile’ at ssocr.c:79:12, inlined from ‘main’ at ssocr.c:529:15: /usr/include/arm-linux-gnueabihf/bits/string_fortified.h:136:10: error: ‘__builtin_strncat’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=] 136 | return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ssocr.c: In function ‘main’: ssocr.c:67:19: note: length computed here 67 | pattern_len = strlen(dir) + strlen(DIR_SEP TMP_FILE_PATTERN) + 1; | ^~~~~~~~~~~ cc1: all warnings being treated as errors make: *** [<builtin>: ssocr.o] Error 1 -------->8-------- As described in a Red Hat blog post[1], this warning cannot be avoided without rewriting the code to not use strncat. I do not intend to do so, instead I just accept that GCC will generate warnings. Thus this commit removes -Werror and -pedantic-errors from the CFLAGS. This fixes compilation on a x86_64 Debian Buster (11) GNU/Linux test system with gcc (Debian 10.2.1-6) 10.2.1 20210110. This strncat warning is the only warning generated by that gcc version. [1] I do not link to that blog post here, because it requires JavaScript to display textual information, which I find unacceptable.
Seven Segment Optical Character Recognition or ssocr for short is a program to recognize digits of a seven segment display. An image of one row of digits is used for input and the recognized number is written to the standard output. The program runs on GNU/Linux (some GNU/Linux distributions provide an ssocr package), FreeBSD (available as a port as well), Mac OS X (Homebrew can be used to install the library Imlib2, used by ssocr), and even on Windows (using Cygwin). ssocr should work on any UNIX-like or POSIX compatible operating system. Unless ssocr is installed via some packaging system, e.g. from a GNU/Linux distribution, it is distributed in source form and needs to be built before it can be used. See the INSTALL file for instructions on how to build ssocr. A manual for ssocr is available in the form of a man page named ssocr.1, you can read it using "make ssocr.1 && man ./ssocr.1" (without the quotes). You can get the current ssocr version from the official ssocr website: https://www.unix-ag.uni-kl.de/~auerswal/ssocr/ (Links to ssocr should point to the official website, not to a convenience copy of the development repository, e.g. on GitHub.) I am usually quicker to reply to emails than to GitHub issues. But increasingly Google blocks emails sent by me, so if you do not receive an answer from me, consider opening a GitHub issue. Perhaps your email provider does not allow you to read my solutions to your ssocr problems. Especially if you are using an @gmail.com or @google.com address, or use your own domain with Google email services, and you do not receive an answer to an email, it is most likely that Google blocked that answer. In that case, you can either follow up with a GitHub issue or use a better email provider than Google. The only problematic email provider I know of is Google. Every file in this repository or archive is licensed under the GNU General Public License version 3 (or later), unless another license is explicitly given in the file itself. This includes all documentation files and the Makefile, and all other files.