Re: cppcheck errors

[Gedare Bloom]

On Tue, Sep 1, 2015 at 5:43 PM, Joel Sherrill  wrote:
>
>
> On 9/1/2015 2:10 PM, Martin Galvan wrote:
>>
>> Hi everyone!
>>
>> I just ran CppCheck again on a fresh clone of the git repo and saw the
>> number of error reports was quite smaller than what I reported before.
>> That's because my previous run was on a (quite older) version; most of
>> those must've been fixed already.
>>
>> Some of the error reports remain, though. I opened a ticket for that
>> and will send a patch that fixes the issues Joel mentioned as worth
>> looking at. I'll open separate tickets for issues reported as
>> "warning" and "portability" (such as the void * thing), and send their
>> respective patches when they're done.
>>
>> While working the fixes I noticed that the following error:
>>
>> [cpukit/librpc/src/rpc/netnamer.c:331]: (error) Resource leak: fd
>>
>> seems to be a false positive. getnetid will be stuck in an endless for
>> loop until it exits through one of the return statements; all of them
>> seem to have their corresponding fclose (if necessary).
>
>
> Great. This code did not originate from RTEMS. It is the original Sun
> RPC/XDR code. :)
>
>> I also noticed some new error reports. It would be nice if Joel (or
>> anyone else who knows the code base better than me) took a look at
>> these and pointed out which ones are third-party code:
>>
>> [cpukit/libfs/src/dosfs/msdos_format.c:1105]: (error) Uninitialized
>> struct member: fmt_params.mbr_copy_sec
>> [cpukit/libfs/src/nfsclient/src/rpcio.c:1203]: (error) Uninitialized
>> variable: stat
>> [cpukit/libmisc/shell/print-ls.c:108]: (error) Invalid number of
>> character ({) when these macros are defined: 'RTEMS_REMOVED'.
>
>
> These are ours to fix.
>
>> [cpukit/libnetworking/libc/getifaddrs.c:251]: (error) Deallocation of
>> an auto-variable results in undefined behaviour.
>> [cpukit/libnetworking/libc/getifaddrs.c:256]: (error) Deallocation of
>> an auto-variable results in undefined behaviour.
>
>
> This code originated in FreeBSD but it sounds interesting enough to look at.
>
>> [cpukit/libnetworking/net/radix.c:935]: (error) Uninitialized variable:
>> error
>> [cpukit/libnetworking/net/radix.c:977]: (error) Uninitialized variable:
>> error
>> [cpukit/libnetworking/netinet/in.c:647]: (error) Memory leak: inm
>> [cpukit/libnetworking/netinet/ip_fw.c:690]: (error) Memory leak: fwc
>
>
> FreeBSD code.
>
But, we are maintaining this for now as an in-tree fork of the
upstream. So feel free to fix anything in libnetworking.

>> [cpukit/mghttpd/mongoose.c:2811] -> [cpukit/mghttpd/mongoose.c:1221]:
>> (error) Mismatching allocation and deallocation: dir
>> [cpukit/mghttpd/mongoose.c:2852] -> [cpukit/mghttpd/mongoose.c:1221]:
>> (error) Mismatching allocation and deallocation: dir
>>
>
> This code is from another project and we are trying to replace it but
> this looks odd enough to investigate and fix.
>
We also maintain this code base as an in-tree fork. So patches are
fine. We can no longer use the upstream due to re-licensing problem.

Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: cppcheck errors

[Martin Galvan]

Hi everyone!

I just ran CppCheck again on a fresh clone of the git repo and saw the
number of error reports was quite smaller than what I reported before.
That's because my previous run was on a (quite older) version; most of
those must've been fixed already.

Some of the error reports remain, though. I opened a ticket for that
and will send a patch that fixes the issues Joel mentioned as worth
looking at. I'll open separate tickets for issues reported as
"warning" and "portability" (such as the void * thing), and send their
respective patches when they're done.

While working the fixes I noticed that the following error:

[cpukit/librpc/src/rpc/netnamer.c:331]: (error) Resource leak: fd

seems to be a false positive. getnetid will be stuck in an endless for
loop until it exits through one of the return statements; all of them
seem to have their corresponding fclose (if necessary).

I also noticed some new error reports. It would be nice if Joel (or
anyone else who knows the code base better than me) took a look at
these and pointed out which ones are third-party code:

[cpukit/libfs/src/dosfs/msdos_format.c:1105]: (error) Uninitialized
struct member: fmt_params.mbr_copy_sec
[cpukit/libfs/src/nfsclient/src/rpcio.c:1203]: (error) Uninitialized
variable: stat
[cpukit/libmisc/shell/print-ls.c:108]: (error) Invalid number of
character ({) when these macros are defined: 'RTEMS_REMOVED'.
[cpukit/libnetworking/libc/getifaddrs.c:251]: (error) Deallocation of
an auto-variable results in undefined behaviour.
[cpukit/libnetworking/libc/getifaddrs.c:256]: (error) Deallocation of
an auto-variable results in undefined behaviour.
[cpukit/libnetworking/net/radix.c:935]: (error) Uninitialized variable: error
[cpukit/libnetworking/net/radix.c:977]: (error) Uninitialized variable: error
[cpukit/libnetworking/netinet/in.c:647]: (error) Memory leak: inm
[cpukit/libnetworking/netinet/ip_fw.c:690]: (error) Memory leak: fwc
[cpukit/mghttpd/mongoose.c:2811] -> [cpukit/mghttpd/mongoose.c:1221]:
(error) Mismatching allocation and deallocation: dir
[cpukit/mghttpd/mongoose.c:2852] -> [cpukit/mghttpd/mongoose.c:1221]:
(error) Mismatching allocation and deallocation: dir
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: cppcheck errors

[Joel Sherrill]

On 9/1/2015 2:10 PM, Martin Galvan wrote:

Hi everyone!

I just ran CppCheck again on a fresh clone of the git repo and saw the
number of error reports was quite smaller than what I reported before.
That's because my previous run was on a (quite older) version; most of
those must've been fixed already.

Some of the error reports remain, though. I opened a ticket for that
and will send a patch that fixes the issues Joel mentioned as worth
looking at. I'll open separate tickets for issues reported as
"warning" and "portability" (such as the void * thing), and send their
respective patches when they're done.

While working the fixes I noticed that the following error:

[cpukit/librpc/src/rpc/netnamer.c:331]: (error) Resource leak: fd

seems to be a false positive. getnetid will be stuck in an endless for
loop until it exits through one of the return statements; all of them
seem to have their corresponding fclose (if necessary).


Great. This code did not originate from RTEMS. It is the original Sun
RPC/XDR code. :)


I also noticed some new error reports. It would be nice if Joel (or
anyone else who knows the code base better than me) took a look at
these and pointed out which ones are third-party code:

[cpukit/libfs/src/dosfs/msdos_format.c:1105]: (error) Uninitialized
struct member: fmt_params.mbr_copy_sec
[cpukit/libfs/src/nfsclient/src/rpcio.c:1203]: (error) Uninitialized
variable: stat
[cpukit/libmisc/shell/print-ls.c:108]: (error) Invalid number of
character ({) when these macros are defined: 'RTEMS_REMOVED'.


These are ours to fix.


[cpukit/libnetworking/libc/getifaddrs.c:251]: (error) Deallocation of
an auto-variable results in undefined behaviour.
[cpukit/libnetworking/libc/getifaddrs.c:256]: (error) Deallocation of
an auto-variable results in undefined behaviour.


This code originated in FreeBSD but it sounds interesting enough to look at.


[cpukit/libnetworking/net/radix.c:935]: (error) Uninitialized variable: error
[cpukit/libnetworking/net/radix.c:977]: (error) Uninitialized variable: error
[cpukit/libnetworking/netinet/in.c:647]: (error) Memory leak: inm
[cpukit/libnetworking/netinet/ip_fw.c:690]: (error) Memory leak: fwc


FreeBSD code.


[cpukit/mghttpd/mongoose.c:2811] -> [cpukit/mghttpd/mongoose.c:1221]:
(error) Mismatching allocation and deallocation: dir
[cpukit/mghttpd/mongoose.c:2852] -> [cpukit/mghttpd/mongoose.c:1221]:
(error) Mismatching allocation and deallocation: dir



This code is from another project and we are trying to replace it but
this looks odd enough to investigate and fix.

--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-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

Re: cppcheck errors

[Daniel Gutson]

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 

Re: cppcheck errors

[Joel Sherrill]

On 8/13/2015 10:52 AM, Daniel Gutson wrote:


El 13/8/2015 12:49, Gedare Bloom ged...@gwu.edu mailto:ged...@gwu.edu 
escribió:
 
  Daniel,
 
  Unknown deadline right now. Probably whenever Joel can get around to
  it! Realistically, we can create a bugfix dot release anytime after
  the release subject to user demand. So, even if you miss the 4.11.0
  release with your patches, we can cut a 4.11.1 after applying the
  patches if you need an official release to work from.

Ok. Yes, we do.

Thanks. Anyway we're making a ranking for a timebox of 2 weeks.


Any updates?


  Gedare
 
  On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson
  daniel.gut...@tallertechnologies.com 
mailto:daniel.gut...@tallertechnologies.com wrote:
   Hi Gedare,
  
   What's the deadline for the official release, if any?
  
   El 13/8/2015 7:15, Gedare Bloom ged...@gwu.edu mailto:ged...@gwu.edu 
escribió:
  
   Daniel,
  
   The release has (unofficially) happened on rtems.git/4.11 branch, from
   which master is slowly diverging. Any patches you want applied before
   the official release need to be (1) associated with a ticket on Trac,
   and (2) apply to both the 4.11 and master branches.
  
   Gedare
  
   On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson
   daniel.gut...@tallertechnologies.com 
mailto:daniel.gut...@tallertechnologies.com wrote:
Hi guys,
   
  we will be posting patches for a number of errors reported by
cppcheck (errors that we can confirm are not false positives).
Please hold on any release.
   
   Daniel.
   
--
   
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 mailto:devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel



--
Joel Sherrill, Ph.D. Director of Research  Development
joel.sherr...@oarcorp.comOn-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

Re: cppcheck errors

[Martin Galvan]

On Thu, Aug 27, 2015 at 6:19 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
 Please note too that there are some false positives, like the realloc one.

Actually, we ruled out most false positives. IIRC that one is an actual bug.

Btw, sorry for the Spanish comment there. It means that if we don't
initialize _ccr we just get a #warning, but the actual problem
remains.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: cppcheck errors

[Martin Galvan]

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):

[c/src/lib/libbsp/shared/umon/umon.h:21]: (error) Invalid number of
character ({) when these macros are defined: '__cplusplus'.
[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().
[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.
[cpukit/libmisc/stackchk/check.c:255]: (portability) 'pattern_area' is
of type 'void *'. When using void pointers in calculations, the
behaviour is undefined.
[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
[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
[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.
[cpukit/libnetworking/rtems/rtems_dhcp.c:401]: (error) Common realloc
mistake: 'dhcp_hostname' nulled but not freed upon failure
[cpukit/librpc/src/rpc/netnamer.c:331]: (error) Resource leak: fd
[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'.
[cpukit/score/cpu/h8300/cpu.c:54]: (error) Uninitialized variable:
_ccr (si no se inicializa, se hace un #warning pero igual existe el
problema)
[cpukit/zlib/gzwrite.c:80]: (error) Uninitialized variable: got
[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
[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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: cppcheck errors

[Joel Sherrill]

On 8/27/2015 4:10 PM, Daniel Gutson wrote:

On Thu, Aug 27, 2015 at 6:06 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:



On 8/13/2015 10:52 AM, Daniel Gutson wrote:



El 13/8/2015 12:49, Gedare Bloom ged...@gwu.edu
mailto:ged...@gwu.edu escribió:
  
   Daniel,
  
   Unknown deadline right now. Probably whenever Joel can get around to
   it! Realistically, we can create a bugfix dot release anytime after
   the release subject to user demand. So, even if you miss the 4.11.0
   release with your patches, we can cut a 4.11.1 after applying the
   patches if you need an official release to work from.

Ok. Yes, we do.

Thanks. Anyway we're making a ranking for a timebox of 2 weeks.



Any updates?


Sorry guys, we have a release tomorrow (which contains some of the top
fixes) but didn't have the time
to send a patch. We will send it early next week.
FWIW, nios had memory leaks but since we are not using that arch we skipped it.
Maybe we can just provide the list until we provide the fixes? Martín?


Both Sebastian and Chris are on holiday this week so there is no
reason to rush. Posting a list of issues would be good but it may
have to be pinged when they are back on line.

I know Chris has experience with the NIOS so he will want to review
those.

--joel


   Gedare
  
   On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson
   daniel.gut...@tallertechnologies.com
mailto:daniel.gut...@tallertechnologies.com wrote:
Hi Gedare,
   
What's the deadline for the official release, if any?
   
El 13/8/2015 7:15, Gedare Bloom ged...@gwu.edu
mailto:ged...@gwu.edu escribió:
   
Daniel,
   
The release has (unofficially) happened on rtems.git/4.11 branch,
from
which master is slowly diverging. Any patches you want applied
before
the official release need to be (1) associated with a ticket on
Trac,
and (2) apply to both the 4.11 and master branches.
   
Gedare
   
On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com
mailto:daniel.gut...@tallertechnologies.com wrote:
 Hi guys,

   we will be posting patches for a number of errors reported by
 cppcheck (errors that we can confirm are not false positives).
 Please hold on any release.

Daniel.

 --

 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 mailto:devel@rtems.org
 http://lists.rtems.org/mailman/listinfo/devel



--
Joel Sherrill, Ph.D. Director of Research  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985






--
Joel Sherrill, Ph.D. Director of Research  Development
joel.sherr...@oarcorp.comOn-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

Re: 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.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.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org

Re: cppcheck errors

[Daniel Gutson]

On Thu, Aug 27, 2015 at 6:06 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:


 On 8/13/2015 10:52 AM, Daniel Gutson wrote:


 El 13/8/2015 12:49, Gedare Bloom ged...@gwu.edu
 mailto:ged...@gwu.edu escribió:
  
   Daniel,
  
   Unknown deadline right now. Probably whenever Joel can get around to
   it! Realistically, we can create a bugfix dot release anytime after
   the release subject to user demand. So, even if you miss the 4.11.0
   release with your patches, we can cut a 4.11.1 after applying the
   patches if you need an official release to work from.

 Ok. Yes, we do.

 Thanks. Anyway we're making a ranking for a timebox of 2 weeks.


 Any updates?

Sorry guys, we have a release tomorrow (which contains some of the top
fixes) but didn't have the time
to send a patch. We will send it early next week.
FWIW, nios had memory leaks but since we are not using that arch we skipped it.
Maybe we can just provide the list until we provide the fixes? Martín?


   Gedare
  
   On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson
   daniel.gut...@tallertechnologies.com
 mailto:daniel.gut...@tallertechnologies.com wrote:
Hi Gedare,
   
What's the deadline for the official release, if any?
   
El 13/8/2015 7:15, Gedare Bloom ged...@gwu.edu
 mailto:ged...@gwu.edu escribió:
   
Daniel,
   
The release has (unofficially) happened on rtems.git/4.11 branch,
 from
which master is slowly diverging. Any patches you want applied
 before
the official release need to be (1) associated with a ticket on
 Trac,
and (2) apply to both the 4.11 and master branches.
   
Gedare
   
On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com
 mailto:daniel.gut...@tallertechnologies.com wrote:
 Hi guys,

   we will be posting patches for a number of errors reported by
 cppcheck (errors that we can confirm are not false positives).
 Please hold on any release.

Daniel.

 --

 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 mailto:devel@rtems.org
 http://lists.rtems.org/mailman/listinfo/devel


 --
 Joel Sherrill, Ph.D. Director of Research  Development
 joel.sherr...@oarcorp.comOn-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

obsolete h8300 was Re: cppcheck errors

[Joel Sherrill]

On 8/27/2015 4:22 PM, Martin Galvan wrote:

On Thu, Aug 27, 2015 at 6:19 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:

Please note too that there are some false positives, like the realloc one.


Actually, we ruled out most false positives. IIRC that one is an actual bug.

Btw, sorry for the Spanish comment there. It means that if we don't
initialize _ccr we just get a #warning, but the actual problem
remains.



The h8 port is up for discussion to be deprecated. As best I can
tell most, if not all, of the models we support are not recommended
for new designs. I think the entire h8300 family is in that situation.

The h8sx and h8s are the only viable parts of the family left.

I wanted to start deprecation discussions now that we are past
branching 4.11. :)

My intention would be to announce ports and BSPs as deprecated in
4.11 and remove them from the master to reduce our work going
forward.

--
Joel Sherrill, Ph.D. Director of Research  Development
joel.sherr...@oarcorp.comOn-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

Re: cppcheck errors

[Gedare Bloom]

Daniel,

The release has (unofficially) happened on rtems.git/4.11 branch, from
which master is slowly diverging. Any patches you want applied before
the official release need to be (1) associated with a ticket on Trac,
and (2) apply to both the 4.11 and master branches.

Gedare

On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
 Hi guys,

   we will be posting patches for a number of errors reported by
 cppcheck (errors that we can confirm are not false positives).
 Please hold on any release.

Daniel.

 --

 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: cppcheck errors

[Gedare Bloom]

Daniel,

Unknown deadline right now. Probably whenever Joel can get around to
it! Realistically, we can create a bugfix dot release anytime after
the release subject to user demand. So, even if you miss the 4.11.0
release with your patches, we can cut a 4.11.1 after applying the
patches if you need an official release to work from.

Gedare

On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
 Hi Gedare,

 What's the deadline for the official release, if any?

 El 13/8/2015 7:15, Gedare Bloom ged...@gwu.edu escribió:

 Daniel,

 The release has (unofficially) happened on rtems.git/4.11 branch, from
 which master is slowly diverging. Any patches you want applied before
 the official release need to be (1) associated with a ticket on Trac,
 and (2) apply to both the 4.11 and master branches.

 Gedare

 On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson
 daniel.gut...@tallertechnologies.com wrote:
  Hi guys,
 
we will be posting patches for a number of errors reported by
  cppcheck (errors that we can confirm are not false positives).
  Please hold on any release.
 
 Daniel.
 
  --
 
  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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: cppcheck errors

[Daniel Gutson]

El 13/8/2015 12:49, Gedare Bloom ged...@gwu.edu escribió:

 Daniel,

 Unknown deadline right now. Probably whenever Joel can get around to
 it! Realistically, we can create a bugfix dot release anytime after
 the release subject to user demand. So, even if you miss the 4.11.0
 release with your patches, we can cut a 4.11.1 after applying the
 patches if you need an official release to work from.

Ok. Yes, we do.

Thanks. Anyway we're making a ranking for a timebox of 2 weeks.


 Gedare

 On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson
 daniel.gut...@tallertechnologies.com wrote:
  Hi Gedare,
 
  What's the deadline for the official release, if any?
 
  El 13/8/2015 7:15, Gedare Bloom ged...@gwu.edu escribió:
 
  Daniel,
 
  The release has (unofficially) happened on rtems.git/4.11 branch, from
  which master is slowly diverging. Any patches you want applied before
  the official release need to be (1) associated with a ticket on Trac,
  and (2) apply to both the 4.11 and master branches.
 
  Gedare
 
  On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson
  daniel.gut...@tallertechnologies.com wrote:
   Hi guys,
  
 we will be posting patches for a number of errors reported by
   cppcheck (errors that we can confirm are not false positives).
   Please hold on any release.
  
  Daniel.
  
   --
  
   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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel