{"thread":{"id":"34726","subject":"CPPCheck found 24 high risk bugs in Git v.1.8.3.4","startedAt":"2013-08-19T17:09:34Z","lastAt":"2013-08-23T19:51:05Z","messageCount":18,"participants":["Koch, Rick (Subcontractor)","Philip Oakley","Jeff King","Junio C Hamano","Johan Herland","Stefan Beller","Erik Faye-Lund","Andreas Schwab","René Scharfe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"225465","messageId":"85C8141E5DAD94428A121F706995A31F010F116FDAD3@MX1.net.tbe.com","threadId":"34726","inReplyTo":null,"subject":"CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Koch, Rick (Subcontractor)","fromEmail":"rick.koch@tbe.com","sentAt":"2013-08-19T17:09:34Z","receivedAt":"2013-08-19T17:09:34Z","isPatch":false,"sender":{"key":"rick.koch@tbe.com","avatar":null},"body":"I'm directing to this e-mail, as it seems to be the approved forum for posting Git bugs. We ran CPPCheck against Git v.1.8.3.4 and found 24 high risk bugs.  Please see the attachment xlsx. \n\nIs there a method to post to the Git community to allow the community to review and debunk as faults positive or develop patches to fix lists code files?\n\nv/r\n\nRoderick (Rick) Koch\nInformation Assurance\nRick.Koch@tbe.com\n\n"},{"id":"225472","messageId":"33FCCE7A2CD5494B88F3C5CDBC341DFD@PhilipOakley","threadId":"34726","inReplyTo":"85C8141E5DAD94428A121F706995A31F010F116FDAD3@MX1.net.tbe.com","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-08-19T20:03:21Z","receivedAt":"2013-08-19T20:03:21Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Koch, Rick (Subcontractor)\" \nSent: Monday, August 19, 2013 6:09 PM\n>I'm directing to this e-mail, as it seems to be the approved forum\n>for posting Git bugs. We ran CPPCheck against Git v.1.8.3.4\n>and found 24 high risk bugs. Please see the attachment xlsx.\n\n>Is there a method to post to the Git community to allow the\n>community to review and debunk as faults positive or develop\n>patches to fix lists code files?\n\n>v/r\n\n>Roderick (Rick) Koch\n>Information Assurance\n>Rick.Koch@tbe.com\n\nWhat OS version / CPPCheck version was this checked on?\n\nIn case other readers don't have a .xlsx reader here is Rick's list in \nplain text (may be white space damaged).\n\nI expect some will be false positives, and some will just be being too \ncautious.\n\nPhilip\n\n description resourceFilePath fileName lineNumber\n nullPointer(CppCheck) \\git-master\\builtin\\add.c add.c 286\n wrongPrintfScanfArgNum(CppCheck) \\git-master\\builtin\\fetch.c\nfetch.c 588\n nullPointer(CppCheck) \\git-master\\builtin\\ls-files.c ls-files.c\n144\n nullPointer(CppCheck) \\git-master\\builtin\\merge.c merge.c 1208\n doubleFree(CppCheck) \\git-master\\builtin\\notes.c notes.c 275\n nullPointer(CppCheck) \\git-master\\builtin\\reflog.c reflog.c 437\n uninitvar(CppCheck) \\git-master\\builtin\\rev-list.c rev-list.c 342\n uninitvar(CppCheck) \\git-master\\builtin\\rev-list.c rev-list.c 342\n uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n2803\n uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n2802\n uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n2805\n memleakOnRealloc(CppCheck) \\git-master\\compat\\win32\\syslog.c\nsyslog.c 46\n uninitvar(CppCheck)\n\\git-master\\contrib\\examples\\builtin-fetch--tool.c builtin-fetch--tool.c\n419\n uninitvar(CppCheck) \\git-master\\fast-import.c fast-import.c 2917\n nullPointer(CppCheck) \\git-master\\line-log.c line-log.c 638\n nullPointer(CppCheck) \\git-master\\mailmap.c mailmap.c 156\n uninitvar(CppCheck) \\git-master\\merge-recursive.c\nmerge-recursive.c 1887\n uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n deallocret(CppCheck) \\git-master\\pretty.c pretty.c 677\n resourceLeak(CppCheck) \\git-master\\refs.c refs.c 3041\n doubleFree(CppCheck) \\git-master\\sequencer.c sequencer.c 924\n nullPointer(CppCheck) \\git-master\\sha1_file.c sha1_file.c 125\n doubleFree(CppCheck) \\git-master\\shell.c shell.c 130\n"},{"id":"225473","messageId":"20130819204044.GA29258@sigill.intra.peff.net","threadId":"34726","inReplyTo":"33FCCE7A2CD5494B88F3C5CDBC341DFD@PhilipOakley","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-19T20:40:44Z","receivedAt":"2013-08-19T20:40:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 19, 2013 at 09:03:21PM +0100, Philip Oakley wrote:\n\n> In case other readers don't have a .xlsx reader here is Rick's list\n> in plain text (may be white space damaged).\n> \n> I expect some will be false positives, and some will just be being\n> too cautious.\n>\n> [...]\n> \n> description resourceFilePath fileName lineNumber\n> nullPointer(CppCheck) \\git-master\\builtin\\add.c add.c 286\n\nHm. That code in v1.8.3.4 reads:\n\n if (pathspec)\n while (pathspec[pc])\n pc++;\n\nWhat's the problem? If pathspec is not properly terminated, we can run\noff the end, but I do see anything to indicate that is the case. What\ndoes the \"nullPointer\" check mean here?\n\n> wrongPrintfScanfArgNum(CppCheck) \\git-master\\builtin\\fetch.c\n> fetch.c 588\n\nLine 588 does not have formatted I/O at all. Are these line numbers\nsomehow not matching what I have in v1.8.3.4?\n\n> nullPointer(CppCheck) \\git-master\\builtin\\ls-files.c ls-files.c\n> 144\n\nThis one looks like:\n\n if (tag && *tag && show_valid_bit &&\n (ce->ce_flags & CE_VALID)) {\n static char alttag[4];\n memcpy(alttag, tag, 3);\n if (isalpha(tag[0]))\n\nwhere the final line is 144. But we have explicitly checked that tag is not\nNULL...\n\n> doubleFree(CppCheck) \\git-master\\builtin\\notes.c notes.c 275\n\nThis one looks like:\n\n if (...) {\n free(buf);\n die(...);\n }\n ...\n free(buf);\n\nwhich might look like a double free if you do not know that die() will\nnever return (it is properly annotated for gcc, but I don't know whether\nCppCheck understands such things).\n\nSo out of the 4 entries I investigated, none of them looks like an\nactual problem. But I'm not even sure I am looking at the right place;\nthese don't even seem like things that would cause a false positive in a\nstatic analyzer.\n\n-Peff\n"},{"id":"225475","messageId":"7vmwodl885.fsf@alter.siamese.dyndns.org","threadId":"34726","inReplyTo":"20130819204044.GA29258@sigill.intra.peff.net","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-19T20:46:18Z","receivedAt":"2013-08-19T20:46:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Aug 19, 2013 at 09:03:21PM +0100, Philip Oakley wrote:\n>\n>> In case other readers don't have a .xlsx reader here is Rick's list\n>> in plain text (may be white space damaged).\n>> \n>> I expect some will be false positives, and some will just be being\n>> too cautious.\n>>\n>> [...]\n>> \n>> description resourceFilePath fileName lineNumber\n>> nullPointer(CppCheck) \\git-master\\builtin\\add.c add.c 286\n>\n> Hm. That code in v1.8.3.4 reads:\n>\n> if (pathspec)\n> while (pathspec[pc])\n> pc++;\n>\n> What's the problem? If pathspec is not properly terminated, we can run\n> off the end, but I do see anything to indicate that is the case. What\n> does the \"nullPointer\" check mean here?\n>\n>> wrongPrintfScanfArgNum(CppCheck) \\git-master\\builtin\\fetch.c\n>> fetch.c 588\n>\n> Line 588 does not have formatted I/O at all. Are these line numbers\n> somehow not matching what I have in v1.8.3.4?\n>\n>> nullPointer(CppCheck) \\git-master\\builtin\\ls-files.c ls-files.c\n>> 144\n>\n> This one looks like:\n>\n> if (tag && *tag && show_valid_bit &&\n> (ce->ce_flags & CE_VALID)) {\n> static char alttag[4];\n> memcpy(alttag, tag, 3);\n> if (isalpha(tag[0]))\n>\n> where the final line is 144. But we have explicitly checked that tag is not\n> NULL...\n>\n>> doubleFree(CppCheck) \\git-master\\builtin\\notes.c notes.c 275\n>\n> This one looks like:\n>\n> if (...) {\n> free(buf);\n> die(...);\n> }\n> ...\n> free(buf);\n>\n> which might look like a double free if you do not know that die() will\n> never return (it is properly annotated for gcc, but I don't know whether\n> CppCheck understands such things).\n>\n> So out of the 4 entries I investigated, none of them looks like an\n> actual problem. But I'm not even sure I am looking at the right place;\n> these don't even seem like things that would cause a false positive in a\n> static analyzer.\n\nAnd the ones I picked at random looks totally bogus, too.\n\n uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n\nThat is\n\n int combine_notes_concatenate(unsigned char *cur_sha1,\n const unsigned char *new_sha1)\n {\n char *cur_msg = NULL, *new_msg = NULL, *buf;\n unsigned long cur_len, new_len, buf_len;\n enum object_type cur_type, new_type;\n int ret;\n\n /* read in both note blob objects */\n if (!is_null_sha1(new_sha1))\n new_msg = read_sha1_file(new_sha1, &new_type, &new_len);\n805: if (!new_msg || !new_len || new_type != OBJ_BLOB) {\n free(new_msg);\n return 0;\n }\n\n\nnew_msg starts out to be NULL, if we did not run read_sha1_file(),\nit will still be NULL and \"if()\" will not look at new_len/new_type\nso their being uninitialized does not matter. If we did run\nread_sha1_file(), and if it returns a non-NULL new_msg, both of\nthese are filled. If read_sha1_file() returns a NULL new_msg, again\nthe other two does not matter.\n\nIn short, the analyzer seems to be giving useless noise for this\none.\n"},{"id":"225477","messageId":"CALKQrgcYtZ58JkSd-qMG9NWeLDaNAhBxXwUTNE8O1LvT+=TF6w@mail.gmail.com","threadId":"34726","inReplyTo":"7vmwodl885.fsf@alter.siamese.dyndns.org","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2013-08-19T20:52:26Z","receivedAt":"2013-08-19T20:52:26Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Mon, Aug 19, 2013 at 10:46 PM, Junio C Hamano wrote:\n> Jeff King writes:\n>> On Mon, Aug 19, 2013 at 09:03:21PM +0100, Philip Oakley wrote:\n>> So out of the 4 entries I investigated, none of them looks like an\n>> actual problem. But I'm not even sure I am looking at the right place;\n>> these don't even seem like things that would cause a false positive in a\n>> static analyzer.\n>\n> And the ones I picked at random looks totally bogus, too.\n>\n> uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n> uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n\nFWIW, I looked at the 3 notes-related ones and reached the same conclusions.\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"225483","messageId":"52128FF7.1040909@googlemail.com","threadId":"34726","inReplyTo":"85C8141E5DAD94428A121F706995A31F010F116FDAD3@MX1.net.tbe.com","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Stefan Beller","fromEmail":"stefanbeller@googlemail.com","sentAt":"2013-08-19T21:36:55Z","receivedAt":"2013-08-19T21:36:55Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On 08/19/2013 07:09 PM, Koch, Rick (Subcontractor) wrote:\n> I'm directing to this e-mail, as it seems to be the approved forum for posting Git bugs. We ran CPPCheck against Git v.1.8.3.4 and found 24 high risk bugs. Please see the attachment xlsx. \n> \n> Is there a method to post to the Git community to allow the community to review and debunk as faults positive or develop patches to fix lists code files?\n> \n\nHi,\n\nif you're using cppcheck as found at https://github.com/danmar/cppcheck \nor http://sourceforge.net/apps/trac/cppcheck/ you really need to review \nthe results, as there are many false positives.\n\nI used that tool for my contributions so far (bug fixes as reported by cppcheck).\nHowever you *really* need to manually review any message cppcheck generates.\nThis is because git is using a C, asm-like coding style for many routines,\nwhereas that cppcheck is rather optimized to find typical C++ errors.\nAnd the styles vary wildy! (cppcheck tries to become no false positives, \nbut it's hard I guess)\n\nI am running that cppcheck tool on git regulary (cppcheck master branch on\ngit master branch), and review for real findings, you're welcome to do so\nas well. :) \n\nThere are other static code analyzers, which have slightly different \ngoals, such as http://css.csail.mit.edu/stack/ which has an incredibly \nlow false positive rate (I found none as of now).\nHowever I think having different tools is a great thing, but you'd need\nto know your tools. ;)\n\nStefan\n\n"},{"id":"225484","messageId":"2A02F37CE50C4BE38860C7D36F1F14CC@PhilipOakley","threadId":"34726","inReplyTo":"85C8141E5DAD94428A121F706995A31F010F116FDADE@MX1.net.tbe.com","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-08-19T21:46:37Z","receivedAt":"2013-08-19T21:46:37Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Koch, Rick (Subcontractor)\" \n\n> Ran CPPCheck 1.5.6 on Windows-XP.\n\nHi Rick,\nThank you for the clarification.\nNormal practice on the list is to use Reply All, so everyone can \nparticipate in the discussion.\n\nIt looks like most of the reports are false positives. My bikeshedding \nthought would be that it is common in Git to inspect all the call sites \nsuch that they don't create the various problems, rather than protect \nagainst the problems within the various functions, which may be a cause \nof the reports (i.e. different philosophical approach to checking).\n\nregards\n\nPhilip\n---\n\nv/r\n\nRoderick (Rick) Koch\nOSF - Information Assurance\nTeam Teledyne / Sentar Inc.\nWork: 256-726-1253\nRick.Koch@tbe.com\n\n\n-----Original Message-----\nFrom: Philip Oakley [mailto:philipoakley@iee.org]\nSent: Monday, August 19, 2013 3:03 PM\nTo: Koch, Rick (Subcontractor); Git List\nSubject: Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4\n\nFrom: \"Koch, Rick (Subcontractor)\" \nSent: Monday, August 19, 2013 6:09 PM\n>I'm directing to this e-mail, as it seems to be the approved forum for\n>posting Git bugs. We ran CPPCheck against Git v.1.8.3.4 and found 24\n>high risk bugs. Please see the attachment xlsx.\n\n>Is there a method to post to the Git community to allow the community\n>to review and debunk as faults positive or develop patches to fix lists\n>code files?\n\n>v/r\n\n>Roderick (Rick) Koch\n>Information Assurance\n>Rick.Koch@tbe.com\n\nWhat OS version / CPPCheck version was this checked on?\n\nIn case other readers don't have a .xlsx reader here is Rick's list in \nplain text (may be white space damaged).\n\nI expect some will be false positives, and some will just be being too \ncautious.\n\nPhilip\n\n description resourceFilePath fileName lineNumber\n nullPointer(CppCheck) \\git-master\\builtin\\add.c add.c 286\n wrongPrintfScanfArgNum(CppCheck) \\git-master\\builtin\\fetch.c \nfetch.c 588\n nullPointer(CppCheck) \\git-master\\builtin\\ls-files.c ls-files.c\n144\n nullPointer(CppCheck) \\git-master\\builtin\\merge.c merge.c 1208\n doubleFree(CppCheck) \\git-master\\builtin\\notes.c notes.c 275\n nullPointer(CppCheck) \\git-master\\builtin\\reflog.c reflog.c 437\n uninitvar(CppCheck) \\git-master\\builtin\\rev-list.c rev-list.c 342\n uninitvar(CppCheck) \\git-master\\builtin\\rev-list.c rev-list.c 342\n uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n2803\n uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n2802\n uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n2805\n memleakOnRealloc(CppCheck) \\git-master\\compat\\win32\\syslog.c \nsyslog.c 46\n uninitvar(CppCheck)\n\\git-master\\contrib\\examples\\builtin-fetch--tool.c builtin-fetch--tool.c\n419\n uninitvar(CppCheck) \\git-master\\fast-import.c fast-import.c 2917\n nullPointer(CppCheck) \\git-master\\line-log.c line-log.c 638\n nullPointer(CppCheck) \\git-master\\mailmap.c mailmap.c 156\n uninitvar(CppCheck) \\git-master\\merge-recursive.c \nmerge-recursive.c 1887\n uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n deallocret(CppCheck) \\git-master\\pretty.c pretty.c 677\n resourceLeak(CppCheck) \\git-master\\refs.c refs.c 3041\n doubleFree(CppCheck) \\git-master\\sequencer.c sequencer.c 924\n nullPointer(CppCheck) \\git-master\\sha1_file.c sha1_file.c 125\n doubleFree(CppCheck) \\git-master\\shell.c shell.c 130\n"},{"id":"225488","messageId":"166132E40AA54EE387BA9B4558823C55@PhilipOakley","threadId":"34726","inReplyTo":"33FCCE7A2CD5494B88F3C5CDBC341DFD@PhilipOakley","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-08-19T22:55:53Z","receivedAt":"2013-08-19T22:55:53Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"----- Original Message ----- \nFrom: \"Philip Oakley\" \n> From: \"Koch, Rick (Subcontractor)\" \n> Sent: Monday, August 19, 2013 6:09 PM\n>>I'm directing to this e-mail, as it seems to be the approved forum\n>>for posting Git bugs. We ran CPPCheck against Git v.1.8.3.4\n>>and found 24 high risk bugs. Please see the attachment xlsx.\n>\n>>Is there a method to post to the Git community to allow the\n>>community to review and debunk as faults positive or develop\n>>patches to fix lists code files?\n>\n>>v/r\n>\n>>Roderick (Rick) Koch\n>>Information Assurance\n>>Rick.Koch@tbe.com\n>\n> What OS version / CPPCheck version was this checked on?\n>\n> In case other readers don't have a .xlsx reader here is Rick's list in \n> plain text (may be white space damaged).\n>\n> I expect some will be false positives, and some will just be being too \n> cautious.\n>\n> Philip\n>\n> description resourceFilePath fileName lineNumber\n> nullPointer(CppCheck) \\git-master\\builtin\\add.c add.c 286\n> wrongPrintfScanfArgNum(CppCheck) \\git-master\\builtin\\fetch.c\n> fetch.c 588\n> nullPointer(CppCheck) \\git-master\\builtin\\ls-files.c ls-files.c\n> 144\n> nullPointer(CppCheck) \\git-master\\builtin\\merge.c merge.c 1208\n> doubleFree(CppCheck) \\git-master\\builtin\\notes.c notes.c 275\n> nullPointer(CppCheck) \\git-master\\builtin\\reflog.c reflog.c 437\n> uninitvar(CppCheck) \\git-master\\builtin\\rev-list.c rev-list.c 342\n> uninitvar(CppCheck) \\git-master\\builtin\\rev-list.c rev-list.c 342\n> uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n> 2803\n> uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n> 2802\n> uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n> 2805\n> memleakOnRealloc(CppCheck) \\git-master\\compat\\win32\\syslog.c\n> syslog.c 46\n\nThis looks like a possible, based on \nhttp://bytes.com/topic/c/answers/215084-can-realloc-potentially-cause-memory-leak \n(Mac's reply, with tweaks)\n\n\"Misuse of realloc CAN cause a memory leak, but only when allocation \nfails\"\n\"if realloc fails, the memory previously pointed to by 'str = \nrealloc(str, ++str_len + 1)' will still be claimed, but you will have \nlost your only pointer to it, because realloc returns NULL on failure. \nThis is a memory leak.\"\n\nWe (those using the compat function) then only provide a warning, so it \ncould repeat endlessly.\n\nEric (cc'd) may be able to clarify if this is a possibility.\n\n> uninitvar(CppCheck)\n> \\git-master\\contrib\\examples\\builtin-fetch--tool.c \n> builtin-fetch--tool.c\n> 419\n> uninitvar(CppCheck) \\git-master\\fast-import.c fast-import.c 2917\n> nullPointer(CppCheck) \\git-master\\line-log.c line-log.c 638\n> nullPointer(CppCheck) \\git-master\\mailmap.c mailmap.c 156\n> uninitvar(CppCheck) \\git-master\\merge-recursive.c\n> merge-recursive.c 1887\n> uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n> uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n> deallocret(CppCheck) \\git-master\\pretty.c pretty.c 677\n> resourceLeak(CppCheck) \\git-master\\refs.c refs.c 3041\n> doubleFree(CppCheck) \\git-master\\sequencer.c sequencer.c 924\n> nullPointer(CppCheck) \\git-master\\sha1_file.c sha1_file.c 125\n> doubleFree(CppCheck) \\git-master\\shell.c shell.c 130\n>\n> --\nPhilip \n"},{"id":"225489","messageId":"CABPQNSZidMv4MEW+SqVm94pX4szw9QW8LFWsvBTOXYH7ezzycw@mail.gmail.com","threadId":"34726","inReplyTo":"166132E40AA54EE387BA9B4558823C55@PhilipOakley","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-08-19T23:15:02Z","receivedAt":"2013-08-19T23:15:02Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"This one seems real, although it's quite theoretical. It should only happen\nin cases where the log-message contains \"%1\", the initial malloc passed and\nreallocing two more bytes failed.\n\nHowever, what's much more of a disaster: \"pos\" is used after the call to\nrealloc might have moved the memory!\n\nI guess something like this should fix both issues. Sorry about the\nlack of indentation, it seems Gmail has regressed, and the old compose\nmode is somehow gone... (also sorry for triple-posting to some of you,\nGmail seems particularly broken today)\n\ndiff --git a/compat/win32/syslog.c b/compat/win32/syslog.c\nindex d015e43..0641f4e 100644\n--- a/compat/win32/syslog.c\n+++ b/compat/win32/syslog.c\n@@ -43,11 +43,14 @@ void syslog(int priority, const char *fmt, ...)\n va_end(ap);\n\n while ((pos = strstr(str, \"%1\")) != NULL) {\n- str = realloc(str, ++str_len + 1);\n- if (!str) {\n+ char *tmp = realloc(str, ++str_len + 1);\n+ if (!tmp) {\n warning(\"realloc failed: '%s'\", strerror(errno));\n+ free(str);\n return;\n }\n+ pos = tmp + (pos - str);\n+ str = tmp;\n memmove(pos + 2, pos + 1, strlen(pos));\n pos[1] = ' ';\n }\n\n\n\nOn Tue, Aug 20, 2013 at 12:55 AM, Philip Oakley wrote:\n> ----- Original Message ----- From: \"Philip Oakley\" \n>\n>> From: \"Koch, Rick (Subcontractor)\" \n>> Sent: Monday, August 19, 2013 6:09 PM\n>>>\n>>> I'm directing to this e-mail, as it seems to be the approved forum\n>>> for posting Git bugs. We ran CPPCheck against Git v.1.8.3.4\n>>> and found 24 high risk bugs. Please see the attachment xlsx.\n>>\n>>\n>>> Is there a method to post to the Git community to allow the\n>>> community to review and debunk as faults positive or develop\n>>> patches to fix lists code files?\n>>\n>>\n>>> v/r\n>>\n>>\n>>> Roderick (Rick) Koch\n>>> Information Assurance\n>>> Rick.Koch@tbe.com\n>>\n>>\n>> What OS version / CPPCheck version was this checked on?\n>>\n>> In case other readers don't have a .xlsx reader here is Rick's list in\n>> plain text (may be white space damaged).\n>>\n>> I expect some will be false positives, and some will just be being too\n>> cautious.\n>>\n>> Philip\n>>\n>> description resourceFilePath fileName lineNumber\n>> nullPointer(CppCheck) \\git-master\\builtin\\add.c add.c 286\n>> wrongPrintfScanfArgNum(CppCheck) \\git-master\\builtin\\fetch.c\n>> fetch.c 588\n>> nullPointer(CppCheck) \\git-master\\builtin\\ls-files.c ls-files.c\n>> 144\n>> nullPointer(CppCheck) \\git-master\\builtin\\merge.c merge.c 1208\n>> doubleFree(CppCheck) \\git-master\\builtin\\notes.c notes.c 275\n>> nullPointer(CppCheck) \\git-master\\builtin\\reflog.c reflog.c 437\n>> uninitvar(CppCheck) \\git-master\\builtin\\rev-list.c rev-list.c 342\n>> uninitvar(CppCheck) \\git-master\\builtin\\rev-list.c rev-list.c 342\n>> uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n>> 2803\n>> uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n>> 2802\n>> uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n>> 2805\n>> memleakOnRealloc(CppCheck) \\git-master\\compat\\win32\\syslog.c\n>> syslog.c 46\n>\n>\n> This looks like a possible, based on\n> http://bytes.com/topic/c/answers/215084-can-realloc-potentially-cause-memory-leak\n> (Mac's reply, with tweaks)\n>\n> \"Misuse of realloc CAN cause a memory leak, but only when allocation fails\"\n> \"if realloc fails, the memory previously pointed to by 'str = realloc(str,\n> ++str_len + 1)' will still be claimed, but you will have lost your only\n> pointer to it, because realloc returns NULL on failure. This is a memory\n> leak.\"\n>\n> We (those using the compat function) then only provide a warning, so it\n> could repeat endlessly.\n>\n> Eric (cc'd) may be able to clarify if this is a possibility.\n>\n>\n>> uninitvar(CppCheck)\n>> \\git-master\\contrib\\examples\\builtin-fetch--tool.c builtin-fetch--tool.c\n>> 419\n>> uninitvar(CppCheck) \\git-master\\fast-import.c fast-import.c 2917\n>> nullPointer(CppCheck) \\git-master\\line-log.c line-log.c 638\n>> nullPointer(CppCheck) \\git-master\\mailmap.c mailmap.c 156\n>> uninitvar(CppCheck) \\git-master\\merge-recursive.c\n>> merge-recursive.c 1887\n>> uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n>> uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n>> deallocret(CppCheck) \\git-master\\pretty.c pretty.c 677\n>> resourceLeak(CppCheck) \\git-master\\refs.c refs.c 3041\n>> doubleFree(CppCheck) \\git-master\\sequencer.c sequencer.c 924\n>> nullPointer(CppCheck) \\git-master\\sha1_file.c sha1_file.c 125\n>> doubleFree(CppCheck) \\git-master\\shell.c shell.c 130\n>>\n>> --\n>\n> Philip\n"},{"id":"225518","messageId":"20130820143306.GC32370@sigill.intra.peff.net","threadId":"34726","inReplyTo":"CABPQNSZidMv4MEW+SqVm94pX4szw9QW8LFWsvBTOXYH7ezzycw@mail.gmail.com","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-20T14:33:06Z","receivedAt":"2013-08-20T14:33:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 20, 2013 at 01:15:02AM +0200, Erik Faye-Lund wrote:\n\n> This one seems real, although it's quite theoretical. It should only happen\n> in cases where the log-message contains \"%1\", the initial malloc passed and\n> reallocing two more bytes failed.\n> \n> However, what's much more of a disaster: \"pos\" is used after the call to\n> realloc might have moved the memory!\n\nYeah, agreed on both counts.\n\n> I guess something like this should fix both issues. Sorry about the\n> lack of indentation, it seems Gmail has regressed, and the old compose\n> mode is somehow gone... (also sorry for triple-posting to some of you,\n> Gmail seems particularly broken today)\n> \n> diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c\n> index d015e43..0641f4e 100644\n> --- a/compat/win32/syslog.c\n> +++ b/compat/win32/syslog.c\n> @@ -43,11 +43,14 @@ void syslog(int priority, const char *fmt, ...)\n> va_end(ap);\n> \n> while ((pos = strstr(str, \"%1\")) != NULL) {\n> - str = realloc(str, ++str_len + 1);\n> - if (!str) {\n> + char *tmp = realloc(str, ++str_len + 1);\n> + if (!tmp) {\n> warning(\"realloc failed: '%s'\", strerror(errno));\n> + free(str);\n> return;\n> }\n> + pos = tmp + (pos - str);\n> + str = tmp;\n> memmove(pos + 2, pos + 1, strlen(pos));\n> pos[1] = ' ';\n> }\n\nYes, that looks like the right solution. You could also convert \"pos\" to\nan integer index rather than a pointer (but then you end up adding it it\nto the pointer in the memmove call, which is probably just as ugly).\n\n-Peff\n"},{"id":"225539","messageId":"87eh9op5gq.fsf@igel.home","threadId":"34726","inReplyTo":"CABPQNSZidMv4MEW+SqVm94pX4szw9QW8LFWsvBTOXYH7ezzycw@mail.gmail.com","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2013-08-20T18:44:37Z","receivedAt":"2013-08-20T18:44:37Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Erik Faye-Lund writes:\n\n> diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c\n> index d015e43..0641f4e 100644\n> --- a/compat/win32/syslog.c\n> +++ b/compat/win32/syslog.c\n> @@ -43,11 +43,14 @@ void syslog(int priority, const char *fmt, ...)\n> va_end(ap);\n>\n> while ((pos = strstr(str, \"%1\")) != NULL) {\n> - str = realloc(str, ++str_len + 1);\n> - if (!str) {\n> + char *tmp = realloc(str, ++str_len + 1);\n> + if (!tmp) {\n> warning(\"realloc failed: '%s'\", strerror(errno));\n> + free(str);\n> return;\n> }\n> + pos = tmp + (pos - str);\n\nPedantically, this is undefined (uses of both pos and str may trap after\nrealloc has freed the original pointer), it is better to calculate the\ndifference before calling realloc.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"225556","messageId":"5213D2C2.6090006@web.de","threadId":"34726","inReplyTo":"87eh9op5gq.fsf@igel.home","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2013-08-20T20:34:10Z","receivedAt":"2013-08-20T20:34:10Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 20.08.2013 20:44, schrieb Andreas Schwab:\n> Erik Faye-Lund writes:\n>\n>> diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c\n>> index d015e43..0641f4e 100644\n>> --- a/compat/win32/syslog.c\n>> +++ b/compat/win32/syslog.c\n>> @@ -43,11 +43,14 @@ void syslog(int priority, const char *fmt, ...)\n>> va_end(ap);\n>>\n>> while ((pos = strstr(str, \"%1\")) != NULL) {\n>> - str = realloc(str, ++str_len + 1);\n>> - if (!str) {\n>> + char *tmp = realloc(str, ++str_len + 1);\n>> + if (!tmp) {\n>> warning(\"realloc failed: '%s'\", strerror(errno));\n>> + free(str);\n>> return;\n>> }\n>> + pos = tmp + (pos - str);\n>\n> Pedantically, this is undefined (uses of both pos and str may trap after\n> realloc has freed the original pointer), it is better to calculate the\n> difference before calling realloc.\n\nAnd while at it, perhaps it's better to follow the suggestion in \nhttp://msdn.microsoft.com/en-us/library/aa363679.aspx under Remarks and \nreplace \"%1\" with \"%1!S!\" instead of \"% 1\".\n\nRené\n"},{"id":"225565","messageId":"CABPQNSZSXgvLw_i25em38B70EgtZrv9iQh8OaCJzYRCk2vjZXQ@mail.gmail.com","threadId":"34726","inReplyTo":"87eh9op5gq.fsf@igel.home","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-08-20T22:26:38Z","receivedAt":"2013-08-20T22:26:38Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Aug 20, 2013 at 8:44 PM, Andreas Schwab wrote:\n> Erik Faye-Lund writes:\n>\n>> diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c\n>> index d015e43..0641f4e 100644\n>> --- a/compat/win32/syslog.c\n>> +++ b/compat/win32/syslog.c\n>> @@ -43,11 +43,14 @@ void syslog(int priority, const char *fmt, ...)\n>> va_end(ap);\n>>\n>> while ((pos = strstr(str, \"%1\")) != NULL) {\n>> - str = realloc(str, ++str_len + 1);\n>> - if (!str) {\n>> + char *tmp = realloc(str, ++str_len + 1);\n>> + if (!tmp) {\n>> warning(\"realloc failed: '%s'\", strerror(errno));\n>> + free(str);\n>> return;\n>> }\n>> + pos = tmp + (pos - str);\n>\n> Pedantically, this is undefined (uses of both pos and str may trap after\n> realloc has freed the original pointer), it is better to calculate the\n> difference before calling realloc.\n\nI don't see how it's undefined. It's using the memory that 'pos'\n*points to* that is undefined, no? The difference between 'pos' and\n'str' should still be the same, it's not like realloc somehow\nmagically updates 'pos'...\n"},{"id":"225566","messageId":"CABPQNSbj4UkjN-MptGZ-NRSd_JzazPwcdVjWM-bpMfFuUM1XMQ@mail.gmail.com","threadId":"34726","inReplyTo":"5213D2C2.6090006@web.de","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-08-20T22:28:33Z","receivedAt":"2013-08-20T22:28:33Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Aug 20, 2013 at 10:34 PM, René Scharfe wrote:\n> Am 20.08.2013 20:44, schrieb Andreas Schwab:\n>\n>> Erik Faye-Lund writes:\n>>\n>>> diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c\n>>> index d015e43..0641f4e 100644\n>>> --- a/compat/win32/syslog.c\n>>> +++ b/compat/win32/syslog.c\n>>> @@ -43,11 +43,14 @@ void syslog(int priority, const char *fmt, ...)\n>>> va_end(ap);\n>>>\n>>> while ((pos = strstr(str, \"%1\")) != NULL) {\n>>> - str = realloc(str, ++str_len + 1);\n>>> - if (!str) {\n>>> + char *tmp = realloc(str, ++str_len + 1);\n>>> + if (!tmp) {\n>>> warning(\"realloc failed: '%s'\", strerror(errno));\n>>> + free(str);\n>>> return;\n>>> }\n>>> + pos = tmp + (pos - str);\n>>\n>>\n>> Pedantically, this is undefined (uses of both pos and str may trap after\n>> realloc has freed the original pointer), it is better to calculate the\n>> difference before calling realloc.\n>\n>\n> And while at it, perhaps it's better to follow the suggestion in\n> http://msdn.microsoft.com/en-us/library/aa363679.aspx under Remarks and\n> replace \"%1\" with \"%1!S!\" instead of \"% 1\".\n>\n\nIf my memory serves me correct, we considered this, but found that\nit wasn't implemented until Vista. I could be mis-remembering, though.\n"},{"id":"225577","messageId":"87y57wnf03.fsf@igel.home","threadId":"34726","inReplyTo":"CABPQNSZSXgvLw_i25em38B70EgtZrv9iQh8OaCJzYRCk2vjZXQ@mail.gmail.com","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2013-08-20T23:01:32Z","receivedAt":"2013-08-20T23:01:32Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Erik Faye-Lund writes:\n\n> I don't see how it's undefined. It's using the memory that 'pos'\n> *points to* that is undefined, no? The difference between 'pos' and\n> 'str' should still be the same, it's not like realloc somehow\n> magically updates 'pos'...\n\nIt does. Think of segmented architectures, where freeing a pointer\ninvalidates its segment, so that even loading the value of the pointer\ntraps. Probably no such architecture is in use any more, though.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"225581","messageId":"xmqqd2p8udtl.fsf@gitster.dls.corp.google.com","threadId":"34726","inReplyTo":"87y57wnf03.fsf@igel.home","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-20T23:45:10Z","receivedAt":"2013-08-20T23:45:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab writes:\n\n> Erik Faye-Lund writes:\n>\n>> I don't see how it's undefined. It's using the memory that 'pos'\n>> *points to* that is undefined, no? The difference between 'pos' and\n>> 'str' should still be the same, it's not like realloc somehow\n>> magically updates 'pos'...\n>\n> It does. Think of segmented architectures, where freeing a pointer\n> invalidates its segment, so that even loading the value of the pointer\n> traps. Probably no such architecture is in use any more, though.\n\nI love seeing that we have somebody who knows and can explain these\ndark corners of ANSI C standard ;-)\n"},{"id":"225582","messageId":"CABPQNSbBMNtww0GKBQVtpE3v=4p86qYBNBmSzDz70TAa7fq7WA@mail.gmail.com","threadId":"34726","inReplyTo":"87y57wnf03.fsf@igel.home","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-08-21T00:01:53Z","receivedAt":"2013-08-21T00:01:53Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Aug 21, 2013 at 1:01 AM, Andreas Schwab wrote:\n> Erik Faye-Lund writes:\n>\n>> I don't see how it's undefined. It's using the memory that 'pos'\n>> *points to* that is undefined, no? The difference between 'pos' and\n>> 'str' should still be the same, it's not like realloc somehow\n>> magically updates 'pos'...\n>\n> It does. Think of segmented architectures, where freeing a pointer\n> invalidates its segment, so that even loading the value of the pointer\n> traps. Probably no such architecture is in use any more, though.\n>\n\nWow, you're right. And since doing it the right way is pretty much the same\ncomplexity (and possibly even a bit easier to follow), that's probably the\nbest thing to go with, then. Thanks for keeping me straight!\n"},{"id":"225741","messageId":"0AED97BABBFA43DAAE14B8355C81AE3B@PhilipOakley","threadId":"34726","inReplyTo":"2A02F37CE50C4BE38860C7D36F1F14CC@PhilipOakley","subject":"Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4 (fetch.c L588)","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-08-23T19:51:05Z","receivedAt":"2013-08-23T19:51:05Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Philip Oakley\" \nSent: Monday, August 19, 2013 10:46 PM\n> From: \"Koch, Rick (Subcontractor)\" \n>\n>> Ran CPPCheck 1.5.6 on Windows-XP.\n>\n> Hi Rick,\n> Thank you for the clarification.\n> Normal practice on the list is to use Reply All, so everyone can \n> participate in the discussion.\n>\n> It looks like most of the reports are false positives. My bikeshedding \n> thought would be that it is common in Git to inspect all the call \n> sites such that they don't create the various problems, rather than \n> protect against the problems within the various functions, which may \n> be a cause of the reports (i.e. different philosophical approach to \n> checking).\n>\n\nI have double checked the reported:\n \"wrongPrintfScanfArgNum(CppCheck) \\git-master\\builtin\\fetch.c\n fetch.c 588\".\n\n fprintf(stderr, \" x %-*s %-*s -> %s\\n\",\n TRANSPORT_SUMMARY(_(\"[deleted]\")),\n REFCOL_WIDTH, _(\"(none)\"), \nprettify_refname(ref->name));\n\n\nAt first it did look like there were not enough parameters to satisfy \nthe \"%-*s\" format strings, given that the second invocation has an \nobvious width. This is the only usage within the prune_refs function.\n\nA little further looking shows that the \"%-*s\" format is used \nextensively in the wider fetch.c and that the TRANSPORT_SUMMARY(), macro \nreturns two values as required by the fprintf.\n\nInaddition those other invocations aren't flagged showing that this is \na false positive, and is a good example for feeding back to CPPCheck (If \nyou wish Rick) as an example so they can see what went wrong.\n\nDoes CPPCheck give more details of 'why' it thinks the other faults are \npresent? (e.g. the double pointer checks which can be tricky)\n\n> regards\n>\n> Philip\n> ---\n>\n> v/r\n>\n> Roderick (Rick) Koch\n> OSF - Information Assurance\n> Team Teledyne / Sentar Inc.\n> Work: 256-726-1253\n> Rick.Koch@tbe.com\n>\n>\n> -----Original Message-----\n> From: Philip Oakley [mailto:philipoakley@iee.org]\n>\n> From: \"Koch, Rick (Subcontractor)\" \n> Sent: Monday, August 19, 2013 6:09 PM\n>>I'm directing to this e-mail, as it seems to be the approved forum for\n>>posting Git bugs. We ran CPPCheck against Git v.1.8.3.4 and found 24\n>>high risk bugs. Please see the attachment xlsx.\n>\n>>Is there a method to post to the Git community to allow the community\n>>to review and debunk as faults positive or develop patches to fix \n>>lists\n>>code files?\n>\n>>v/r\n>\n>>Roderick (Rick) Koch\n>>Information Assurance\n>>Rick.Koch@tbe.com\n>\n> What OS version / CPPCheck version was this checked on?\n>\n> In case other readers don't have a .xlsx reader here is Rick's list in \n> plain text (may be white space damaged).\n>\n> I expect some will be false positives, and some will just be being too \n> cautious.\n>\n> Philip\n>\n> description resourceFilePath fileName lineNumber\n> nullPointer(CppCheck) \\git-master\\builtin\\add.c add.c 286\n> wrongPrintfScanfArgNum(CppCheck) \\git-master\\builtin\\fetch.c \n> fetch.c 588\n\nFalse positive.\n\n> nullPointer(CppCheck) \\git-master\\builtin\\ls-files.c ls-files.c\n> 144\n> nullPointer(CppCheck) \\git-master\\builtin\\merge.c merge.c 1208\n> doubleFree(CppCheck) \\git-master\\builtin\\notes.c notes.c 275\n> nullPointer(CppCheck) \\git-master\\builtin\\reflog.c reflog.c 437\n> uninitvar(CppCheck) \\git-master\\builtin\\rev-list.c rev-list.c 342\n> uninitvar(CppCheck) \\git-master\\builtin\\rev-list.c rev-list.c 342\n> uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n> 2803\n> uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n> 2802\n> uninitvar(CppCheck) \\git-master\\compat\\regex\\regcomp.c regcomp.c\n> 2805\n> memleakOnRealloc(CppCheck) \\git-master\\compat\\win32\\syslog.c \n> syslog.c 46\n\nTrue report.\n\n> uninitvar(CppCheck)\n> \\git-master\\contrib\\examples\\builtin-fetch--tool.c \n> builtin-fetch--tool.c\n> 419\n> uninitvar(CppCheck) \\git-master\\fast-import.c fast-import.c 2917\n> nullPointer(CppCheck) \\git-master\\line-log.c line-log.c 638\n> nullPointer(CppCheck) \\git-master\\mailmap.c mailmap.c 156\n> uninitvar(CppCheck) \\git-master\\merge-recursive.c \n> merge-recursive.c 1887\n> uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n> uninitvar(CppCheck) \\git-master\\notes.c notes.c 805\n> deallocret(CppCheck) \\git-master\\pretty.c pretty.c 677\n> resourceLeak(CppCheck) \\git-master\\refs.c refs.c 3041\n> doubleFree(CppCheck) \\git-master\\sequencer.c sequencer.c 924\n> nullPointer(CppCheck) \\git-master\\sha1_file.c sha1_file.c 125\n> doubleFree(CppCheck) \\git-master\\shell.c shell.c 130\n>\n>\n> --\nPhilip \n"}]}