On Thu, Aug 27, 2015 at 6:38 PM, Joel Sherrill
<joel.sherr...@oarcorp.com> wrote:
>
>
> 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.
This is because + and - operators are not defined for void*, since
addr(pointer + k) = addr(pointer) + k * sizeof(*pointer),
but since pointer is void*, sizeof(void) is not defined, that's why it
is non-standard. However, gcc extensions
considers this case as char*, which is exactly the way to make this
portable: just cast it to char* before doing the arithmetics.
>
>> [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.
At the end it goes to the same binary, no matter where it came from,
so IMHO it may be worth
to send a patch to where this comes from.
>
>> [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
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
Skype: dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
