Since I have used imlib2-config since "the beginning," I prefer
to keep it as long as it is available. But for systems with a
newer Imlib2 version, a fallback to pkg-config is required.
At least on still supported Debian and Ubuntu GNU/Linux systems,
both pkg-config and imlib2-config can be used to determine the
LDFLAGS needed to link against Imlib2. Current upstream Imlib2
no longer provides imlib2-config, but only pkg-config data.
In 2017, I received a report of ssocr being used to interpret the
status display of some Chinese table tennis robot. The user had
implemented character recognition in a Perl script that interpreted
the ASCII art segments in ssocr's debug output.
The new ssocr character set "tt_robot" implements the exact same
segment interpretations as found in the Perl script mentioned above.
This even includes two erroneous '7' definitions that work around
recognition problems.
If the string length of the value of the environment variable TMP
is too big, adding the length of a slash and the temporary file
name might overflow, which would result in an insufficient memory
allocation for the absolute file name.
I do not know if that can actually happen in any existing operating
system and platform combination where ssocr can be used.
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.
GitHub user "watkit" reported to have needed
make CPPFLAGS=-I/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/Tk.framework/Versions/8.5/Headers/
to build ssocr on a 2020 m1 Mac mini.
While I know of seven segment displays that use
_
| |
as 'N', ssocr detects the size of the individual seven segment
displays and thus always sees this as
_
| |
| |
unless the digit boundary detection fails.
This commit is intended as a reminder for me that I have already
thought about this issue.
I have encountered problems sending email to users of GMail, to
users of Google email services using domain names different from
gmail.com, and to Google employees using their corporate email
account.
Google is the only email provider that does not accept my emails,
as far as I know.
This adds an option to enable white spece detection, and two
further options to control the operation of white space detection.
White space detection (--print-spaces) is intended for use cases
where digit (resp. character) grouping is important for correct
interpretation. One use case is the recognition of superimposed
dates in photographic images.
This commit also increases the version number to 2.21.0 and tweaks
some debug output.
C compilers are getting more aggressive with warnings and are producing
more false positives. While I intend to keep ssocr compiling without
warnings (as in the last 15 years), I do not use the newest C compilers,
but rather the GCC version included in a stable GNU/Linux distribution,
it may take some time for me to encounter those problems myself, and thus
it may take some time for me to work around them.
A user reported a compilation failure due to new warnings in GCC 10.1.
Since I currently use GCC 7.5.0 from Ubuntu 18.04 LTS, I do not see
those warnings yet, and thus cannot test any workarounds yet.
A first investigation into the issue hints at a need to replace valid code
with code invalid for GCC's default C standard version (necessitating
the specification of a newer C standard in the CFLAGS) to work around
said problem. I have no idea if there are additional warnings with GCC
10.1 after working around that one. Since Google blocks my emails to
the reporting user, I cannot even communicate to find this out. Thus any
code changes will have to wait for either a GCC version with additional
warnings arriving in my GNU/Linux distribution, or establishment of a
different communication channel, e.g., a GitHub issue.
There have been issues with the basic security features a modern C
compiler should provide, hindering compilation of ssocr. One way to work
around those is to disable use of the broken features. Another way is
to use a quality C compiler, e.g., a stable GCC release.
Google is blocking my answer emails to @gmail.com addresses. So I
can only advise to use a real email provider, not Google. If one
cannot do that, or does not want to, one can open a GitHub issue
instead.
Erik Auerswald