Potential bugs in externals detected on OBS

While building RPMs of purr-data for openSUSE Leap 5.1 and 5.0 on the Open Build Service, I noticed the following problem reports in the build logs. They're running rpmlint there at the end of the build, which also tries to find potential issues in the code. I think that this is a useful service, although it's also somewhat annoying as it prevents my builds from finishing. ;-)

It might be that these are all just false positives, but it can't hurt to have a look at them anyway some time. I invite anyone interested to join me, it's always good to have a few more eyeballs sifting through such issues.

The issues are from the build log at https://build.opensuse.org/build/home:aggraef/openSUSE_Leap_15.1/x86_64/purr-data/_log, from which I extracted the interesting bits below (note that the original log may have disappeared or replaced with a new log when you read this, so I'm also attaching a full snapshot of the log below).

[ 1905s] I: A function overflows or underflows an array access. This could be a real error,
[ 1905s]    but occasionaly this condition is also misdetected due to loop unrolling or strange pointer
[ 1905s]    handling. So this is warning only, please review.
[ 1905s] W: purr-data arraysubscript /home/abuild/rpmbuild/BUILD/purr-data-2.9.0+git4163+485302f9/externals/jasch_lib/detox/detox.c:484

[ 1905s] I: Program is using implicit definitions of functions getting
[ 1905s]    pointers or implemented by macros. These functions need to use their
[ 1905s]    correct prototypes to allow correct argument passing on e.g. x86_64 .
[ 1905s]      - Implicit memory/string functions need #include <string.h>.
[ 1905s]      - Implicit *printf functions need #include <stdio.h>.
[ 1905s]      - Implicit *printf functions need #include <stdio.h>.
[ 1905s]      - Implicit *read* functions need #include <unistd.h>.
[ 1905s]      - Implicit *recv* functions need #include <sys/socket.h>.
[ 1905s] W: purr-data implicit-pointer-decl s_inter.c:992
[ 1905s] W: purr-data implicit-pointer-decl s_loader.c:222
[ 1905s] W: purr-data implicit-pointer-decl scramble~.c:77

[ 1906s] I: Program causes undefined operation
[ 1906s]    (likely same variable used twice and post/pre incremented in the same expression).
[ 1906s]    e.g. x = x++; Split it in two operations.
[ 1906s] W: purr-data sequence-point /home/abuild/rpmbuild/BUILD/purr-data-2.9.0+git4163+485302f9/externals/jasch_lib/detox/detox.c:343, 360, 601
[ 1906s] W: purr-data sequence-point control/serial_bird.c:132
[ 1906s] W: purr-data sequence-point control/serial_ms.c:72
[ 1906s] W: purr-data sequence-point control/serial_mt.c:34
[ 1906s] W: purr-data sequence-point tabsort.c:92
[ 1906s] W: purr-data sequence-point tabsort2.c:114
[ 1906s] 
[ 1906s] I: Program is likely to break with new gcc. Try -fno-strict-aliasing.
[ 1906s] W: purr-data strict-aliasing-punning cwiidmodule.c:201
[ 1906s] W: purr-data strict-aliasing-punning dumpOSC.c:914
[ 1906s] W: purr-data strict-aliasing-punning readsfv~.c:671, 684
[ 1906s] W: purr-data strict-aliasing-punning svf~.c:60, 61
[ 1906s] 
[ 1906s] I: Program is using uninitialized variables.
[ 1906s]    Note the difference between "is used" and "may be used"
[ 1906s] W: purr-data uninitialized-variable cxc_split.c:34
[ 1906s] 
[ 1906s] I: Statement might potentially overflow a destination buffer, where a size larger
[ 1906s]     than the actual buffer was specified
[ 1906s] E: purr-data destbufferoverflow cooled~.c:262
[ 1906s] 
[ 1906s] I: Program returns random data in a function
[ 1906s] E: purr-data no-return-in-nonvoid-function /home/abuild/rpmbuild/BUILD/purr-data-2.9.0+git4163+485302f9/externals/iem/iemmatrix/src/mtx_dispersive_dline.c:154
[ 1906s] 
[ 1906s] I: Program returns random data in a function
[ 1906s] E: purr-data no-return-in-nonvoid-function /home/abuild/rpmbuild/BUILD/purr-data-2.9.0+git4163+485302f9/externals/iem/iemmatrix/src/mtx_dispersive_dline.c:154

Full build log: obs-buildlog.txt

The build was from current master (plus !312 (merged) which doesn't modify any C/C++sources), so the line numbers should be interpreted relative to rev. 53166958.

@ico I guess that one of your modules is also in there (strict-aliasing-punning cwiidmodule.c:201), so it would be nice if you could have a look at that line and tell me whether you're actually doing some nasty type punning there, or whether that line looks ok to you.