On 8/27/2015 4:15 PM, Martin Galvan wrote:
On Thu, Aug 27, 2015 at 6:10 PM, Daniel Gutson
<daniel.gut...@tallertechnologies.com> wrote:
Maybe we can just provide the list until we provide the fixes? MartÃn?
Gladly. Keep in mind we ran cppcheck only on the modules we use
(though some things may've slipped in, like nios):
Most of these are worth looking at. Honestly, the ones on the tcp/ip
stack and other directly imported code aren't going to get touched.
[c/src/lib/libbsp/shared/umon/umon.h:21]: (error) Invalid number of
character ({) when these macros are defined: '__cplusplus'.
Spot check shows this is missing the closing magic for extern "C".
I see a couple more of these below and we should fix though.
[cpukit/libmisc/dumpbuf/dumpbuf.c:69]: (error) Undefined behavior:
Variable 'line_buffer' is used as parameter and destination in
s[n]printf().
[cpukit/libmisc/dumpbuf/dumpbuf.c:76]: (error) Undefined behavior:
Variable 'line_buffer' is used as parameter and destination in
s[n]printf().
This should be looked at.
[cpukit/libmisc/stackchk/check.c:285] ->
[cpukit/libmisc/stackchk/check.c:294]: (performance) Variable
'pattern_ok' is reassigned a value before the old one has been used.
This should be looked at.
[cpukit/libmisc/stackchk/check.c:255]: (portability) 'pattern_area' is
of type 'void *'. When using void pointers in calculations, the
behaviour is undefined.
Not sure what to do about this. I think this is defined behavior
for at least GCC.
[cpukit/libnetworking/kern/kern_subr.c:93]: (portability) 'cp' is of
type 'void *'. When using void pointers in calculations, the behaviour
is undefined.
[cpukit/libnetworking/kern/uipc_socket2.c:616]: (error) Uninitialized
variable: o
Imported code.
[cpukit/libnetworking/lib/ftpfs.c:704] ->
[cpukit/libnetworking/lib/ftpfs.c:709]: (performance) Variable
'port_socket' is reassigned a value before the old one has been used.
[cpukit/libnetworking/lib/tftpDriver.c:503]: (error) Common realloc
mistake: 'current' nulled but not freed upon failure
Need to be looked at.
[cpukit/libnetworking/libc/ether_addr.c:72]: (portability) scanf
without field width limits can crash with huge input data on some
versions of libc.
[cpukit/libnetworking/libc/ether_addr.c:94]: (portability) scanf
without field width limits can crash with huge input data on some
versions of libc.
[cpukit/libnetworking/libc/gethostbyht.c:233]: (error) Common realloc
mistake: 'hostmap' nulled but not freed upon failure
[cpukit/libnetworking/libc/ns_addr.c:112]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:120]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:128]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:137]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
All imported code. maybe the realloc() is worth addressing.
[cpukit/libnetworking/rtems/rtems_dhcp.c:401]: (error) Common realloc
mistake: 'dhcp_hostname' nulled but not freed upon failure
This is the only one in our code.
[cpukit/librpc/src/rpc/netnamer.c:331]: (error) Resource leak: fd
Probably should be looked at.
[cpukit/posix/include/rtems/posix/ptimer.h:33]: (error) Invalid number
of character ({) when these macros are defined: '__cplusplus'.
[cpukit/rtems/include/rtems/rtems/dpmemimpl.h:116]: (error) Invalid
number of character ({) when these macros are defined: '__cplusplus'.
Easy.
[cpukit/score/cpu/h8300/cpu.c:54]: (error) Uninitialized variable:
_ccr (si no se inicializa, se hace un #warning pero igual existe el
problema)
Appears to be confused by conditional or inline asm.
[cpukit/zlib/gzwrite.c:80]: (error) Uninitialized variable: got
Hmm.. but third party code.
[tools/build/binpatch.c:104]: (error) Resource leak: ifp
[tools/build/binpatch.c:63]: (error) Uninitialized variable: off
[tools/build/unhex.c:238]: (error) Resource leak: outfp
Need to be looked at but these are host side utilities. There is likely
no resource leak since it is a process. The unitialized variable needs
looking at. We fixed a number of issues flagged by CodeSonar in these
last year.
[tools/cpu/nios2/memory.c:99]: (error) Uninitialized variable: memory
[tools/cpu/nios2/ptf.c:542]: (error) fprintf format string has 1
parameters but only 0 are given.
[tools/cpu/nios2/ptf.c:580]: (error) Memory leak: new_prefix
Those worth a look. But again a host-side utility.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
