cppcheck errors

[Joel Sherrill]

On 8/27/2015 4:15 PM, Martin Galvan wrote:
> On Thu, Aug 27, 2015 at 6:10 PM, Daniel Gutson
> <daniel.gutson at 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.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985