[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #15 from David Binderman --- (In reply to Robert Dubner from comment #14) > This exercise has been extremely useful. ... > Thanks again to David Binderman for sending me down this road; it's been > educational and useful. You are welcome. Glad to be useful. You now know a lot more than I do about cppcheck.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 Robert Dubner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Robert Dubner --- This exercise has been extremely useful. The use of cppcheck is a bit of an art form. Using it has exposed a few real problems, but we've reached a point in the COBOL code where even Jim and I are having discussions that don't quite reach to the point of disagreements about which cppcheck warnings to eliminate by suppression, or by changing the code. Some are a matter of style, and that becomes a matter of opinion. However, we have eliminated enough warnings that I am closing this PR. I have scripted cppcheck for libgcobol/*.cc and gcc/cobol/*.cc into my extended cobolworx testsuite, so they run routinely. With the following inputs to cppcheck, they generate no warnings. The configuration file: cat >$CFG < EndOfText The command line: cppcheck --inline-suppr --enable=all --force --language=c++ --std=c++14 --library=$CFG \ --check-level=exhaustive \ --suppress=unusedFunction \ --suppress=missingInclude \ --suppress=missingIncludeSystem \ --suppress=postfixOperator \ --suppress=checkersReport \ --suppress=noExplicitConstructor \ --suppress=unmatchedSuppression \ $(cat $FILES) > $RESULT 2>&1 The final check: cat $RESULT | grep -v -E "^Checking.*$" Thanks again to David Binderman for sending me down this road; it's been educational and useful.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #13 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:8b06c58c4ae83d4007510f2d2c74ee979bc2b86a commit r16-2713-g8b06c58c4ae83d4007510f2d2c74ee979bc2b86a Author: Robert Dubner Date: Fri Aug 1 10:37:38 2025 -0400 cobol: Minor changes to quiet cppcheck warnings. [PR119324] gcc/cobol/ChangeLog: PR cobol/119324 * cbldiag.h (location_dump): Inline suppression of knownConditionTrueFalse. * genapi.cc (parser_statement_begin): Combine two if() statements. * genutil.cc (get_binary_value): File-level suppression of duplicateBreak. * symbols.cc (symbol_elem_cmp): File-level suppression of duplicateBreak.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #12 from James K. Lowden --- As of today, except for gcc/cobol/genapi.cc, I have only a couple dozen outstanding reports from cppcheck. One deserves attention at some point but is not causing a problem. Most are cppcheck failing to recognize what "auto" means. It was a useful exercise, if only to make the code safer for some well meaning stranger to hack on. I'm leaving the PR open until we deal with the 504 message regarding cppcheck. Once that's done, I will mark it as "resolved" unless and until the cppcheck issue I filed regarding ODR proves fruitful. That is, I think the ODR reports are invalid. I think it is based on the "multiple definitions" coming from the same file, included once via an absolute path and once via a relative path. Because I don't see how our build system could supply both paths, I suspect the answer lies somewhere in cppcheck.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #11 from James K. Lowden --- I am adding gcc/cobol/Makefile.cppcheck to the repository. It uses the bear(1) package to build a "project" file, which I minimized to build only the files in the gcc/cobol directory. It then invokes cppcheck 2.17. N.B., it does not work with cppheck 2.7, which comes with Ubuntu LTS 22. That version requires the source directory on the command line, and then quickly dies with a segfault on at least three of the inputs. The bear(1) utility produces a json project file by monitoring the commands issued by make. AFAICT it doesn't invoke Flex/Bison. It does check compilation of their outputs. cppcheck reports something about the Flex output scan.cc. That I'm ignoring. cppcheck produced many valid complaints about single-argument constructors, although a few are by design. It found one potential NULL dereference and two logic errors. All but the NULL dereference were corrected on Friday with 37f5fdd008399c239e0689f2e864519505c78c7e. The NULL dereference fix is pending. I posted two comments to the cppcheck discussion about false positives. One regards a report of returning a reference to a temporary, where the returned value is a static local variable. The other regards the ODR report. That report has the form ODR violation for X, note A, note B where A and B are, I think, the supposedly conflicting definitions. In this case, both A and B refer to symbols.h:158 (and, for another X, symbols.h:183), where A is an absolute path and B is a relative path. I suspect the report is incorrect, but otherwise the message is. There is no evidence of more than one defintion for cbl_domain_t or cbl_domain_elem_t. Outstanding as of now are reports of suspect copy constructors and assignment operators for classes with dynamic allocation. Those are in the crosshairs.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-05-23 Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Ever confirmed|0 |1
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #10 from Robert Dubner --- Yes, thank you. I don't mean to seem like I am being argumentative. I can't help but note that your selected commands generated three lines of output from a 50K cppcheck.list file that is 766 lines long. That seems...odd. That's a lot of what you apparently regard as false positives or unimportant. It's hard for me to know, from a standing start, which options to cppcheck are relevant, and which lines of output to regard as important. But what you posted here is extremely helpful.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #9 from David Binderman --- (In reply to Robert Dubner from comment #8) > Jim has repaired some of them. I don't know which. See comment 1. > So, in order for cppcheck to be useful, especially in the face of its > extensive configurability, what I find to be Cppcheck's sketchy > documentation, and my current complete ignorance of how to use it, it would > be very useful for me to know exactly how you are using it as a starting > point. gcc $ find trunk/gcc/cobol/ -name \*.cc -print | sort > file.list gcc $ wc -l file.list 14 file.list gcc $ cppcheck --version Cppcheck 2.17.1 gcc $ (date; cppcheck --enable=all --force --language=c++ `cat file.list`;date) > cppcheck.out 2>&1 gcc $ grep passedByValue cppcheck.out trunk/gcc/cobol/copybook.h:133:34: performance: Function parameter 'input' should be passed by const reference. [passedByValue] trunk/gcc/cobol/exceptg.h:77:56: performance: Function parameter 'files' should be passed by const reference. [passedByValue] trunk/gcc/cobol/inspect.h:203:62: performance: Function parameter 'oper' should be passed by const reference. [passedByValue] gcc $ grep clarifyCalculation cppcheck.out gcc $ grep identicalInnerCondition cppcheck.out gcc $ Exact enough ? That's from recent sources in the last 24 hours or so.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #8 from Robert Dubner --- I don't like making blind changes. I need to duplicate the report you created so that I know that any changes I make actually fix cppcheck outputs without creating new ones. The "problems" reported by Cppcheck are not causing any difficulties that I am aware of. Certainly the various test suites are all succeeding with those problems in place. Jim has repaired some of them. I don't know which. The source code has changed significantly since you first posted about it, so I can't be sure about line numbers. So, in order for cppcheck to be useful, especially in the face of its extensive configurability, what I find to be Cppcheck's sketchy documentation, and my current complete ignorance of how to use it, it would be very useful for me to know exactly how you are using it as a starting point. I guess I am asking you to treat it like a bug report. If Cppcheck .cfg files have been created for coping with GCC source code fiels, I would appreciate knowing what they are. There must be complete command lines for running cppcheck and for grepping the result; I need to know what those are. Because right now I can't seem to make it work at all. I regard learning how to use Cppcheck in a way consistent with what you have developed as at least as important as making stylistic changes about clarifying operator precedence.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #7 from David Binderman --- (In reply to Robert Dubner from comment #6) > I don't know what I am doing differently, or why I am seeing errors that > you're not. Instead of trying to duplicate my results, you could try just fixing the problems I reported.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #6 from Robert Dubner --- I compiled and installed cppcheck 2.17, which was a bit of an intelligence test. The error messages were very chatty, but didn't actually tell me what I needed to know. It took a while, but the internet came through. So I have a working installation of cppcheck 2.17 Here is simple attempt: bob@doobie:~/repos/gcc-cobol/gcc/cobol$ cppcheck genapi.cc Checking genapi.cc ... genutil.h:104:1: error: There is an unknown macro here somewhere. Configuration is required. If FIXED_WIDE_INT is a macro then please configure it. [unknownMacro] FIXED_WIDE_INT(128) get_power_of_ten(int n); ^ Checking genapi.cc: INCORPORATE_ANALYZER... Checking genapi.cc: LINE_TICK... Checking genapi.cc: YDFLTYPE;YDFLTYPE_IS_DECLARED... Checking genapi.cc: YYLTYPE;YYLTYPE_IS_DECLARED... Checking genapi.cc: _CBLDIAG_H... Checking genapi.cc: _SYMBOLS_H_... Checking genapi.cc: condition_lists... Checking genapi.cc: yy_flex_debug... Since there are a bunch of .h file in gcc/, I tried this: bob@doobie:~/repos/gcc-cobol/gcc/cobol$ cppcheck genapi.cc --force -I.. Checking genapi.cc ... ../hwint.h:62:5: error: #error "Unable to find a suitable type for HOST_WIDE_INT" [preprocessorErrorDirective] #error "Unable to find a suitable type for HOST_WIDE_INT" ^ I don't know what I am doing differently, or why I am seeing errors that you're not.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #5 from David Binderman --- cppcheck says a lot of things that are true but not useful. I use the following grep command to find the more interesting material: grep -E "performance:| error:| warning:| style:" filename
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324
--- Comment #4 from Robert Dubner ---
I fear that my ignorance is holed up in a bit of a fortress.
I have installed Cppcheck 2.7 on an Ubuntu 22.04 LTS x86_64 system.
When I try to run it on just one file that you mention, I get the following. I
haven't a clue how to interpret it, or to make it more meaningful. Part of my
problem is that the cppcheck documentation indicates that things known as
"configurations" are of major importance, without giving me anything like a
clue what a "configuration" is.
$ cppcheck genapi.cc --force --enable=all
Checking genapi.cc ...
genutil.h:104:1: error: There is an unknown macro here somewhere. Configuration
is required. If FIXED_WIDE_INT is a macro then please configure it.
[unknownMacro]
FIXED_WIDE_INT(128) get_power_of_ten(int n);
^
Checking genapi.cc: INCORPORATE_ANALYZER...
Checking genapi.cc: LINE_TICK...
Checking genapi.cc: YDFLTYPE;YDFLTYPE_IS_DECLARED...
cbldiag.h:82:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
void error_msg( const YYLTYPE& loc, const char gmsgid[], ... );
^
cbldiag.h:84:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
void dialect_error( const YYLTYPE& loc, const char term[], const char dialect[]
);
^
cbldiag.h:93:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
void cbl_unimplemented_at( const YYLTYPE& loc, const char *gmsgid, ... );
^
cbldiag.h:102:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
void gcc_location_set( const YYLTYPE& loc );
^
symbols.h:156:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
const char * consistent_encoding_check( const YYLTYPE& loc, const char input[]
);
^
symbols.h:167:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
cbl_domain_elem_t( const YYLTYPE& loc,
^
symbols.h:187:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
cbl_domain_t( const YYLTYPE& loc,
^
symbols.h:575:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
void report_invalid_initial_value(const YYLTYPE& loc) const;
^
symbols.h:654:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
YYLTYPE loc;
^
symbols.h:672:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
cbl_refer_t( const YYLTYPE& loc, cbl_field_t *field, bool all = false )
^
symbols.h:1371:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
YYLTYPE loc;
^
symbols.h:1387:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
cbl_alphabet_t(const YYLTYPE& loc, cbl_encoding_t enc)
^
symbols.h:1398:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
cbl_alphabet_t( const YYLTYPE& loc, const cbl_name_t name,
^
symbols.h:1419:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
add_sequence( const YYLTYPE& loc, const unsigned char seq[] ) {
^
symbols.h:1430:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you wan
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #3 from David Binderman --- (In reply to Robert Dubner from comment #2) > David, I am not familiar with cppcheck. I have installed it, but when I try > to run it I don't see what you are describing here. > > Can you tell me how to configure and run cppcheck to duplicate these results? Have you tried cppcheck over a simple helloWorld.c C source code file to make sure it is installed ok ? If that works, then you have a good install. I use flags --enable=all --force when I run cppcheck. My usual command line is: $ (date;cat file.list | xargs -n 1000 ~/cppcheck/trunk/cppcheck --enable=all --force --language=c++ -j 8;date) > cppcheckOutput/cppcheck.95.out 2>&1 & HTH. If any problems, please let me know.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #2 from Robert Dubner --- (In reply to David Binderman from comment #0) > I tried out the static analyser cppcheck on > the source code of /cobol/. > > The most important things it said were: David, I am not familiar with cppcheck. I have installed it, but when I try to run it I don't see what you are describing here. Can you tell me how to configure and run cppcheck to duplicate these results? Thanks. > > 1. > > gcc/cobol/symbols.cc:246:64: performance: Function parameter 'args' should > be passed by const reference. [passedByValue] > > 2. > > gcc/cobol/lexio.cc:854:56: performance: Function parameter 'cm' should be > passed by const reference. [passedByValue] > > 3. > > gcc/cobol/symfind.cc:503:55: performance: Function parameter 'names' should > be passed by const reference. [passedByValue] > > 4. > > gcc/cobol/genapi.cc:1777:78: style: Clarify calculation precedence for '&' > and '?'. [clarifyCalculation] > > 5. > > gcc/cobol/genapi.cc:1778:78: style: Clarify calculation precedence for '&' > and '?'. [clarifyCalculation] > > 6. > > gcc/cobol/genapi.cc:15638:25: warning: Identical inner 'if' condition is > always true. [identicalInnerCondition] > > 7. > > gcc/cobol/genapi.cc:16702:11: warning: Identical inner 'if' condition is > always true. [identicalInnerCondition]
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #1 from James K. Lowden --- Partly fixed by 9b78ad2cbf0. 1. function eliminated: "Function parameter 'args'": 2. dts::regex_search emulates std::regex_search, which passes cm by reference, to write to it. 3. done: parameter 'names' should be passed by const reference 4. done: Clarify calculation precedence 5. done: Clarify calculation precedence 6 and 7 remain TODO.
