Created attachment 578136 [details, diff] Fixes the problem I need the attached patch to make it work again.
Have you please reported upstream?
No. Should I do it? I'm not really sure why it got broken - or why it worked previously. I updated my system last Sunday. The source code of backend/cfg-obj.c does not differ between iscan-2.30.2 and 2.30.3 - maybe compiler settings are different, also GCC was upgraded from 7 to 8...
I reported it to Alesh.Slovak@avasys.jp which seems to be the last maintainer according to the AUTHORS file in the sources. Lets see if I get an answer...
It's best to avoid having custom patches and to be as close to upstream as possible. Of course, we can patch if it's necessary, but then all downstream distros have to do it, which is not great ;) Thanks for contacting the authors!
The e-mail address Alesh.Slovak@avasys.jp seems to be no longer in use. At least my e-mail could not be delivered;(
I've met the same issue and the patch resolved it. Does anybody knows when this will be applied as a patch in the upstream? If not, could you please apply it as a custom patch for the current iscan release?
I was hit by this problem too. It is caused by a change in Glibc 2.29. https://sourceware.org/ml/libc-announce/2019/msg00000.html > An archaic GNU extension to scanf, under which '%as', '%aS', and > '%a[...]' meant to scan a string and allocate space for it with > malloc, is now restricted to programs compiled in C89 or C++98 mode > with _GNU_SOURCE defined. This extension conflicts with C99's use of > '%a' to scan a hexadecimal floating-point number, which is now > available to programs compiled as C99 or C++11 or higher, regardless > of _GNU_SOURCE. > > POSIX.1-2008 includes the feature of allocating a buffer for string input > with malloc, using the modifier letter 'm' instead. Programs using > '%as', '%aS', or '%a[...]' with the old GNU meaning should change to > '%ms', '%mS', or '%m[...]' respectively. Programs that wish to use > the C99 '%a' no longer need to avoid _GNU_SOURCE.
This patch has been included in the 2.30.4.2 version bump.
