Non null-terminated variables
Static source code analysis tool for C and C++ code
Brought to you by:
danielmarjamaki
Menu
▾
▴
When I enter the following code into the cppcheck online demo, (version 1.86), I get the following return:
void f()
{
char myvar[3];
memcpy(myvar, "xxx", 3);
}
Cppcheck 1.86
[test.cpp:4]: (warning, inconclusive) The buffer 'myvar' is not null-terminated after the call to memcpy(). This will cause bugs later in the code if the code assumes the buffer is null-terminated.
Done!
However, when I try to run either version 1.86 or 1.89 on the same code myself, it does not report this warning. I even run it with --inconclusive. What am I missing?
We have places in the code non-null-terminated variables are causing issues. Can anyone point me to what I need to do to get it to report/behave the same way the online demo did?
did you try
--enable=warningalso?Yes, also --enable=all, did not work. However, I discovered that I had to have BOTH --enable and --inconclusive for it to catch it. It would be nice if the online demo would display/specify whatever parameters or switches it is being run with. I'm running 1.86, same as the online demo states:
C:\Program Files\Cppcheck>cppcheck.exe --version
Cppcheck 1.86
My test file:
C:\Program Files\Cppcheck>type test1.c
main()
{
char myvar[3];
memcpy(myvar, "xxx", 3);
}
Results:
C:\Program Files\Cppcheck>cppcheck.exe --enable=all .\test1.c
Checking test1.c ...
C:\Program Files\Cppcheck>cppcheck.exe --inconclusive .\test1.c
Checking test1.c ...
C:\Program Files\Cppcheck>cppcheck.exe --enable=warning --inconclusive .\test1.c
Checking test1.c ...
[test1.c:4]: (warning, inconclusive) The buffer 'myvar' is not null-terminated after the call to memcpy().
However, running with the above parameters that WORKED did NOT catch it if I changed the memcpy to memset. "memset(myvar, 'x', 3);". Seems to me it should catch the same condition whether it is memset or memcpy....???
Furthermore, once I had the right parameters for it to "catch" the memcpy, I upgraded from 1.86 to 1.89, and..... even using the same parameters, 1.89 does NOT display the non-null-terminated warning. What do I have to do to get 1.89 to flag this?
I tested the same code (and used same parameters, both cmd line and GUI) with both 1.86 and 1.87 - both flagged the non-null-terminated variable. Starting with 1.88 (AND 1.89) - it does not. Is there a parameter I need to set for the newer versions, or has this functionality been removed?
Also, I earlier posted a question about memset.....?
Sorry for the late answer. Currently it is not possible to get the warning with memcpy. It was removed in 1.88 (https://github.com/danmar/cppcheck/commit/2ecfae0a9849d94b577942b2601835e4b309c2cc). The commit message says it didn't work well, but I don't know what didn't work well. As far as I could see, there has never been warnings for memset
I also received the following email from a fojtik@users.sourceforge.net:
"I attempted to write something to cppcheck discussion and my post waits for moderation.
Could you allow my post? I hope that I did not write anything wrong."
I know nothing about this, I am not a moderator on this board.
Ok, thx for the heads-up. Guess I'll be sticking with version 1.87 for the forseeable future. I also installed the plug-in for Visual Studio, it caught the memcpy as well, so thankfully it wasn't removed from it also.
I don't remember. But I assume I meant that there was false positives. I guess it would be possible to how it works by reverting that commit and run the script cppcheck/tools/test-my-pr.py for a couple of hours.
We had an issue where a non-null terminated variable caused us much grief. After finding and fixing it, I turned to cppcheck to see if it could identify other instances in over 100+ modules. So far it has done a great job - every place it has flagged we have verified that it does so correctly. Since this is vital we will be continuing with 1.87 and NO upgrading unless such a time/version where that functionality is restored. I'm more than willing to accept an occasional false positive to catch many problems than to miss catching many potential problems to avoid the occasional false positive. So far we've identified ~50 or so and every one of them has checked out as a valid catch. Just wish they would do the same for memset as well. Thx.
Perhaps the function names should be set from a library config, so then users could set it for additional functions besides what cppcheck currently checks.
Yes. Some such configuration should be added.
I really like the way the Visual Studio plug-in has a screen which allows you to easily select exactly which things to look for and ignore.