{"thread":{"id":"45211","subject":"[PATCH] travis-ci: run scan-build every time","startedAt":"2017-02-24T17:38:36Z","lastAt":"2017-02-27T00:35:00Z","messageCount":7,"participants":["Samuel Lijin","Lars Schneider","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"312522","messageId":"CAJZjrdXP3n5fOLx4rEEkbJT7JBMPUqk4Qdutm6KpvMVUMwCSPQ@mail.gmail.com","threadId":"45211","inReplyTo":null,"subject":"[PATCH] travis-ci: run scan-build every time","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-02-24T17:29:05Z","receivedAt":"2017-02-24T17:38:36Z","isPatch":true,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":"Introduces the scan-build static code analysis tool from the Clang\nproject to all Travis CI builds. Installs clang (since scan-build\nneeds clang as a dependency) to make this possible (on macOS, also\nupdates PATH to allow scan-build to be invoked without referencing the\nfull path).\n---\n\nA build with this patch can be found at [1]. Note that if reports *are*\ngenerated, this doesn't allow us to access them, and if we dumped\nthe reports as build artifacts, I'm not sure where we would want to\ndump them to.\n\nIt's worth noting that there seems to be a weird issue with scan-build\nwhere it *will* generate a report for something locally, but won't do it\non Travis. See [2] for an example where I have a C program with a\nvery obvious memory leak but scan-build on Travis doesn't generate\na report (despite complaining about it in stdout), even though it does\non my local machine.\n\n[1] https://travis-ci.org/sxlijin/git/builds/204853233\n[2] https://travis-ci.org/sxlijin/travis-testing/jobs/205025319#L331-L342\n\n .travis.yml | 10 +++++-----\n 1 file changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/.travis.yml b/.travis.yml\nindex 9c63c8c3f..1038b1b3d 100644\n--- a/.travis.yml\n+++ b/.travis.yml\n@@ -20,6 +20,7 @@ addons:\n - language-pack-is\n - git-svn\n - apache2\n+ - clang\n\n env:\n global:\n@@ -78,9 +79,8 @@ before_install:\n brew update --quiet\n # Uncomment this if you want to run perf tests:\n # brew install gnu-time\n- brew install git-lfs gettext\n- brew link --force gettext\n- brew install caskroom/cask/perforce\n+ brew install git-lfs gettext caskroom/cask/perforce llvm\n+ brew link --force gettext llvm\n ;;\n esac;\n echo \"$(tput setaf 6)Perforce Server Version$(tput sgr0)\";\n@@ -92,9 +92,9 @@ before_install:\n mkdir -p $HOME/travis-cache;\n ln -s $HOME/travis-cache/.prove t/.prove;\n\n-before_script: make --jobs=2\n+before_script: scan-build make --jobs=2\n\n-script: make --quiet test\n+script: scan-build make --quiet test\n\n after_failure:\n - >\n--\n2.11.1\n"},{"id":"312667","messageId":"BAB1EE0E-B258-4108-AE24-110172086DE4@gmail.com","threadId":"45211","inReplyTo":"CAJZjrdXP3n5fOLx4rEEkbJT7JBMPUqk4Qdutm6KpvMVUMwCSPQ@mail.gmail.com","subject":"Re: [PATCH] travis-ci: run scan-build every time","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-02-25T21:48:52Z","receivedAt":"2017-02-25T21:56:25Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 24 Feb 2017, at 18:29, Samuel Lijin wrote:\n> \n> Introduces the scan-build static code analysis tool from the Clang\n> project to all Travis CI builds. Installs clang (since scan-build\n> needs clang as a dependency) to make this possible (on macOS, also\n> updates PATH to allow scan-build to be invoked without referencing the\n> full path).\n\nThis is a pretty neat idea. However, I think this should become a\ndedicated job in a TravisCI build (similar to the Documentation job [1])\nbecause:\n a) We don't want to build and test a scan-build version of Git (AFAIK\n scan-build kind of proxies the compiler to do its job - I don't if\n this has any side effects)\n b) We don't want to slow down the other builds\n c) It should be enough to run scan-build once on Linux per build\n\nI ran scan-build on the current master and it detected 72 potential bugs [2]. \nI looked through a few of them and they seem to be legitimate. If the list agrees\nthat running scan-build is a useful thing and that these problems should be fixed\nthen we could:\n\n(1) Add scan-build check to Travis CI but only print errors as warning\n(2) Fix the 72 existing bugs over time\n(3) Turn scan-build warnings into errors\n\n\n[1] https://github.com/git/git/blob/e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7/.travis.yml#L42-L53\n[2] https://larsxschneider.github.io/git-scan/\n\n\n> ---\n> \n> A build with this patch can be found at [1]. Note that if reports *are*\n> generated, this doesn't allow us to access them, and if we dumped\n> the reports as build artifacts, I'm not sure where we would want to\n> dump them to.\n\nWe could upload the results to a Git repo and then use GitHub pages to serve\nit. I did that with my run here: https://larsxschneider.github.io/git-scan/\n\n\n> It's worth noting that there seems to be a weird issue with scan-build\n> where it *will* generate a report for something locally, but won't do it\n> on Travis. See [2] for an example where I have a C program with a\n> very obvious memory leak but scan-build on Travis doesn't generate\n> a report (despite complaining about it in stdout), even though it does\n> on my local machine.\n> \n> [1] https://travis-ci.org/sxlijin/git/builds/204853233\n> [2] https://travis-ci.org/sxlijin/travis-testing/jobs/205025319#L331-L342\n\nScan-build stores the report in some temp folder. I assume you can't access\nthis folder on TravisCI. Try the scan-build option \"-o scan-build-results\"\nto store the report in the local directory. \n\n\n> \n> .travis.yml | 10 +++++-----\n> 1 file changed, 5 insertions(+), 5 deletions(-)\n> \n> diff --git a/.travis.yml b/.travis.yml\n> index 9c63c8c3f..1038b1b3d 100644\n> --- a/.travis.yml\n> +++ b/.travis.yml\n> @@ -20,6 +20,7 @@ addons:\n> - language-pack-is\n> - git-svn\n> - apache2\n> + - clang\n> \n> env:\n> global:\n> @@ -78,9 +79,8 @@ before_install:\n> brew update --quiet\n> # Uncomment this if you want to run perf tests:\n> # brew install gnu-time\n> - brew install git-lfs gettext\n> - brew link --force gettext\n> - brew install caskroom/cask/perforce\n> + brew install git-lfs gettext caskroom/cask/perforce llvm\n> + brew link --force gettext llvm\n\nThis wouldn't be necessary if we only scan on Linux.\n\n\n> ;;\n> esac;\n> echo \"$(tput setaf 6)Perforce Server Version$(tput sgr0)\";\n> @@ -92,9 +92,9 @@ before_install:\n> mkdir -p $HOME/travis-cache;\n> ln -s $HOME/travis-cache/.prove t/.prove;\n> \n> -before_script: make --jobs=2\n> +before_script: scan-build make --jobs=2\n\nI think we should run it like this:\n\nscan-build -analyze-headers --status-bugs --keep-going --force-analyze-debug-code make --jobs=2\n\nThis way TravisCI would be notified via the return code if scan-build detected\nerrors I think.\n\n\n> -script: make --quiet test\n> +script: scan-build make --quiet test\n\nWhy do you want to scan the tests?\n\n\nCheers,\nLars"},{"id":"312670","messageId":"20170225223146.ixubnwqkfol5q2gn@sigill.intra.peff.net","threadId":"45211","inReplyTo":"BAB1EE0E-B258-4108-AE24-110172086DE4@gmail.com","subject":"Re: [PATCH] travis-ci: run scan-build every time","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-25T22:31:46Z","receivedAt":"2017-02-25T22:31:59Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 25, 2017 at 10:48:52PM +0100, Lars Schneider wrote:\n\n> \n> > On 24 Feb 2017, at 18:29, Samuel Lijin wrote:\n> > \n> > Introduces the scan-build static code analysis tool from the Clang\n> > project to all Travis CI builds. Installs clang (since scan-build\n> > needs clang as a dependency) to make this possible (on macOS, also\n> > updates PATH to allow scan-build to be invoked without referencing the\n> > full path).\n> \n> This is a pretty neat idea. However, I think this should become a\n> dedicated job in a TravisCI build (similar to the Documentation job [1])\n> because:\n> a) We don't want to build and test a scan-build version of Git (AFAIK\n> scan-build kind of proxies the compiler to do its job - I don't if\n> this has any side effects)\n> b) We don't want to slow down the other builds\n> c) It should be enough to run scan-build once on Linux per build\n\nYeah. I am all for static analysis, but I agree it should be its own\njob. Especially as it can be quite noisy with false positives (and I\nreally think before any static analysis is useful we need to figure out\na way to suppress the false positives, so that we can see the signal in\nthe noise).\n\nFully a third of the problem cases found are dead assignments or\nincrements. I looked at a few, and I think the right strategy is to tell\nthe tool \"no really, our code is fine\". For instance, it complains\nabout:\n\n argc = parse_options(argc, argv, ...);\n\nwhen argc is not used again later. Sure, that assignment is doing\nnothing. But from a maintainability perspective, I'd much rather have a\ndead assignment (that the compiler is free to remove) then for somebody\nto later add a loop like:\n\n for (i = 0; i < argc; i++)\n something(argv[i]);\n\nwhich will read past the end of the rearranged argv (and probably\n_wouldn't_ be caught by static analysis, because the hidden dependency\nbetween argc and argv is buried inside the parse_options() call).\n\nSo there is definitely some bug-fixing to be done, but I think there is\nalso some work in figuring out how to suppress these useless reports.\nTurning off the dead-assignment checker is one option, but I actually\nthink it _could_ produce useful results. It just isn't in these cases.\nSo I'd much rather if we can somehow suppress the specific callsites.\n\n> I ran scan-build on the current master and it detected 72 potential bugs [2]. \n> I looked through a few of them and they seem to be legitimate. If the list agrees\n> that running scan-build is a useful thing and that these problems should be fixed\n> then we could:\n> \n> (1) Add scan-build check to Travis CI but only print errors as warning\n> (2) Fix the 72 existing bugs over time\n> (3) Turn scan-build warnings into errors\n\nIf they are warnings socked away in a Travis CI job that nobody looks\nout, then I doubt anybody is going to bother fixing them.\n\nNot that step (1) hurts necessarily, but I don't think it's really doing\nanything until step (2) is finished.\n\nI took a look at a few of the non-dead-assignment ones and some of them\nare obviously false positives. E.g., in check_pbase_path(), it claims\nthat done_pbase_paths might be NULL. But that value just went through\nALLOC_GROW() with a non-zero value, which would either have allocated or\ndied.\n\nThere are other cases where it complains that a strbuf's \"buf\" parameter\nmight be NULL. That _shouldn't_ be the case, as it is an invariant of\nstrbuf. It might be a bug, but it is certainly not a bug where the\nanalyzer is pointing.\n\nI won't be surprised at all if there are a bunch of real bugs in that\nlist. But I think the interesting work at this point is not a CI build,\nbut somebody locally slogging through scan-build and categorizing each\none.\n\n-Peff\n"},{"id":"312672","messageId":"70DA368F-97FB-4492-811D-CCDF4F237939@gmail.com","threadId":"45211","inReplyTo":"20170225223146.ixubnwqkfol5q2gn@sigill.intra.peff.net","subject":"Re: [PATCH] travis-ci: run scan-build every time","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-02-25T23:02:33Z","receivedAt":"2017-02-25T23:11:26Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 25 Feb 2017, at 23:31, Jeff King wrote:\n> \n> On Sat, Feb 25, 2017 at 10:48:52PM +0100, Lars Schneider wrote:\n> \n>> \n>>> On 24 Feb 2017, at 18:29, Samuel Lijin wrote:\n>>> \n>>> Introduces the scan-build static code analysis tool from the Clang\n>>> project to all Travis CI builds. Installs clang (since scan-build\n>>> needs clang as a dependency) to make this possible (on macOS, also\n>>> updates PATH to allow scan-build to be invoked without referencing the\n>>> full path).\n>> \n>> This is a pretty neat idea. However, I think this should become a\n>> dedicated job in a TravisCI build (similar to the Documentation job [1])\n>> because:\n>> a) We don't want to build and test a scan-build version of Git (AFAIK\n>> scan-build kind of proxies the compiler to do its job - I don't if\n>> this has any side effects)\n>> b) We don't want to slow down the other builds\n>> c) It should be enough to run scan-build once on Linux per build\n> \n> Yeah. I am all for static analysis, but I agree it should be its own\n> job. Especially as it can be quite noisy with false positives (and I\n> really think before any static analysis is useful we need to figure out\n> a way to suppress the false positives, so that we can see the signal in\n> the noise).\n> \n> Fully a third of the problem cases found are dead assignments or\n> increments. I looked at a few, and I think the right strategy is to tell\n> the tool \"no really, our code is fine\". For instance, it complains\n> about:\n> \n> argc = parse_options(argc, argv, ...);\n> \n> when argc is not used again later. Sure, that assignment is doing\n> nothing. But from a maintainability perspective, I'd much rather have a\n> dead assignment (that the compiler is free to remove) then for somebody\n> to later add a loop like:\n> \n> for (i = 0; i < argc; i++)\n> something(argv[i]);\n> \n> which will read past the end of the rearranged argv (and probably\n> _wouldn't_ be caught by static analysis, because the hidden dependency\n> between argc and argv is buried inside the parse_options() call).\n> \n> So there is definitely some bug-fixing to be done, but I think there is\n> also some work in figuring out how to suppress these useless reports.\n\nThat makes sense. I suspected that this assignment was intentional\nbut I wasn't sure why. I didn't know about the rearrangement of argv.\n\nApparently an \"(void)argc;\" silences this warning. Would that be too\nugly to bear? :-)\n\n\n> Turning off the dead-assignment checker is one option, but I actually\n> think it _could_ produce useful results. It just isn't in these cases.\n> So I'd much rather if we can somehow suppress the specific callsites.\n> \n>> I ran scan-build on the current master and it detected 72 potential bugs [2]. \n>> I looked through a few of them and they seem to be legitimate. If the list agrees\n>> that running scan-build is a useful thing and that these problems should be fixed\n>> then we could:\n>> \n>> (1) Add scan-build check to Travis CI but only print errors as warning\n>> (2) Fix the 72 existing bugs over time\n>> (3) Turn scan-build warnings into errors\n> \n> If they are warnings socked away in a Travis CI job that nobody looks\n> out, then I doubt anybody is going to bother fixing them.\n> \n> Not that step (1) hurts necessarily, but I don't think it's really doing\n> anything until step (2) is finished.\n\nAgreed.\n\n\n- Lars"},{"id":"312677","messageId":"CAJZjrdXg=jTXO+Dox9gTby-_JX+Lw_deihbUmbHe8V92dWJ0tg@mail.gmail.com","threadId":"45211","inReplyTo":"BAB1EE0E-B258-4108-AE24-110172086DE4@gmail.com","subject":"Re: [PATCH] travis-ci: run scan-build every time","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-02-26T02:09:52Z","receivedAt":"2017-02-26T02:10:38Z","isPatch":true,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":"On Sat, Feb 25, 2017 at 3:48 PM, Lars Schneider\n wrote:\n>\n>> On 24 Feb 2017, at 18:29, Samuel Lijin wrote:\n>>\n>> It's worth noting that there seems to be a weird issue with scan-build\n>> where it *will* generate a report for something locally, but won't do it\n>> on Travis. See [2] for an example where I have a C program with a\n>> very obvious memory leak but scan-build on Travis doesn't generate\n>> a report (despite complaining about it in stdout), even though it does\n>> on my local machine.\n>>\n>> [1] https://travis-ci.org/sxlijin/git/builds/204853233\n>> [2] https://travis-ci.org/sxlijin/travis-testing/jobs/205025319#L331-L342\n>\n> Scan-build stores the report in some temp folder. I assume you can't access\n> this folder on TravisCI. Try the scan-build option \"-o scan-build-results\"\n> to store the report in the local directory.\n\nThat occurred to me, but I don't quite think that's the issue. I just\nnoticed that on the repo I use to test build matrices, jobs 1-8 don't\ngenerate a report, but 9-14 and 19-20 do [1]. I don't think it's an\nissue with write permissions (scan-build complains much more vocally\nif that happens), but it doesn't seem to matter if the output dir is\nin the tmpfs [2] or a local directory [3].\n\n[1] https://travis-ci.org/sxlijin/travis-testing/builds/205054253\n[2] https://travis-ci.org/sxlijin/git/jobs/205028920#L1000\n[2] https://travis-ci.org/sxlijin/git/jobs/205411705#L998\n\n>> @@ -78,9 +79,8 @@ before_install:\n>> brew update --quiet\n>> # Uncomment this if you want to run perf tests:\n>> # brew install gnu-time\n>> - brew install git-lfs gettext\n>> - brew link --force gettext\n>> - brew install caskroom/cask/perforce\n>> + brew install git-lfs gettext caskroom/cask/perforce llvm\n>> + brew link --force gettext llvm\n>\n> This wouldn't be necessary if we only scan on Linux.\n\nAgreed. I'm not sure if macOS static analysis would bring any specific\nbenefits; I don't really have much experience with static analysis\ntools one way or another, so I'm happy to defer on this decision.\n\n\n>> -script: make --quiet test\n>> +script: scan-build make --quiet test\n>\n> Why do you want to scan the tests?\n\nBrain fart on my end.\n\n> Cheers,\n> Lars\n"},{"id":"312686","messageId":"71030110-EB19-4F54-95F1-443D3EAE5286@gmail.com","threadId":"45211","inReplyTo":"CAJZjrdXg=jTXO+Dox9gTby-_JX+Lw_deihbUmbHe8V92dWJ0tg@mail.gmail.com","subject":"Re: [PATCH] travis-ci: run scan-build every time","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-02-26T14:12:30Z","receivedAt":"2017-02-26T14:13:56Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 26 Feb 2017, at 03:09, Samuel Lijin wrote:\n> \n> On Sat, Feb 25, 2017 at 3:48 PM, Lars Schneider\n> wrote:\n>> \n>>> On 24 Feb 2017, at 18:29, Samuel Lijin wrote:\n>>> \n>>> It's worth noting that there seems to be a weird issue with scan-build\n>>> where it *will* generate a report for something locally, but won't do it\n>>> on Travis. See [2] for an example where I have a C program with a\n>>> very obvious memory leak but scan-build on Travis doesn't generate\n>>> a report (despite complaining about it in stdout), even though it does\n>>> on my local machine.\n>>> \n>>> [1] https://travis-ci.org/sxlijin/git/builds/204853233\n>>> [2] https://travis-ci.org/sxlijin/travis-testing/jobs/205025319#L331-L342\n>> \n>> Scan-build stores the report in some temp folder. I assume you can't access\n>> this folder on TravisCI. Try the scan-build option \"-o scan-build-results\"\n>> to store the report in the local directory.\n> \n> That occurred to me, but I don't quite think that's the issue. I just\n> noticed that on the repo I use to test build matrices, jobs 1-8 don't\n> generate a report, but 9-14 and 19-20 do [1]. I don't think it's an\n> issue with write permissions (scan-build complains much more vocally\n> if that happens), but it doesn't seem to matter if the output dir is\n> in the tmpfs [2] or a local directory [3].\n> \n> [1] https://travis-ci.org/sxlijin/travis-testing/builds/205054253\n> [2] https://travis-ci.org/sxlijin/git/jobs/205028920#L1000\n> [2] https://travis-ci.org/sxlijin/git/jobs/205411705#L998\n\nScan-build somehow replaces the compiler. My guess is that you \ntell scan-build to substitute clang but \"make\" is really using \ngcc or something? I reported something strange about the compilers\non TravisCI some time ago but I can't find it anymore. I think I \nremember on OSX they always use clang even if you define gcc. \nMaybe it makes sense to reach out to TravisCI support in case \nthis is a bug on their end?\n\nBased on your work I tried the following and it seems to work:\nhttps://travis-ci.org/larsxschneider/git/jobs/205507241\nhttps://github.com/larsxschneider/git/commit/faf4ecfdca1a732459c1f93c334928ee2826d490\n\n- Lars"},{"id":"312701","messageId":"CAJZjrdVaUvrfq5+fAurrtMME42Om+-QyXZEVpNDGAbG9iieggA@mail.gmail.com","threadId":"45211","inReplyTo":"71030110-EB19-4F54-95F1-443D3EAE5286@gmail.com","subject":"Re: [PATCH] travis-ci: run scan-build every time","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-02-27T00:34:08Z","receivedAt":"2017-02-27T00:35:00Z","isPatch":true,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":"On Sun, Feb 26, 2017 at 8:12 AM, Lars Schneider\n wrote:\n>\n>> On 26 Feb 2017, at 03:09, Samuel Lijin wrote:\n>>\n>> On Sat, Feb 25, 2017 at 3:48 PM, Lars Schneider\n>> wrote:\n>>>\n>>>> On 24 Feb 2017, at 18:29, Samuel Lijin wrote:\n>>>>\n>>>> It's worth noting that there seems to be a weird issue with scan-build\n>>>> where it *will* generate a report for something locally, but won't do it\n>>>> on Travis. See [2] for an example where I have a C program with a\n>>>> very obvious memory leak but scan-build on Travis doesn't generate\n>>>> a report (despite complaining about it in stdout), even though it does\n>>>> on my local machine.\n>>>>\n>>>> [1] https://travis-ci.org/sxlijin/git/builds/204853233\n>>>> [2] https://travis-ci.org/sxlijin/travis-testing/jobs/205025319#L331-L342\n>>>\n>>> Scan-build stores the report in some temp folder. I assume you can't access\n>>> this folder on TravisCI. Try the scan-build option \"-o scan-build-results\"\n>>> to store the report in the local directory.\n>>\n>> That occurred to me, but I don't quite think that's the issue. I just\n>> noticed that on the repo I use to test build matrices, jobs 1-8 don't\n>> generate a report, but 9-14 and 19-20 do [1]. I don't think it's an\n>> issue with write permissions (scan-build complains much more vocally\n>> if that happens), but it doesn't seem to matter if the output dir is\n>> in the tmpfs [2] or a local directory [3].\n>>\n>> [1] https://travis-ci.org/sxlijin/travis-testing/builds/205054253\n>> [2] https://travis-ci.org/sxlijin/git/jobs/205028920#L1000\n>> [2] https://travis-ci.org/sxlijin/git/jobs/205411705#L998\n>\n> Scan-build somehow replaces the compiler. My guess is that you\n> tell scan-build to substitute clang but \"make\" is really using\n> gcc or something?\n\nYour hunch is spot-on. I took a look at the Makefile and lo and\nbehold, it overrides $CC [1]. Looking at the commit which introduced\nit [2] I have to admit I'm somewhat surprised that scan-build works at\nall...\n\n[1] https://github.com/git/git/blob/master/Makefile#L454\n[2] https://github.com/git/git/commit/6d62c983f7d91565a15e49955b3ed94ae7c73434\n\n> I reported something strange about the compilers\n> on TravisCI some time ago but I can't find it anymore. I think I\n> remember on OSX they always use clang even if you define gcc.\n> Maybe it makes sense to reach out to TravisCI support in case\n> this is a bug on their end?\n>\n> Based on your work I tried the following and it seems to work:\n> https://travis-ci.org/larsxschneider/git/jobs/205507241\n> https://github.com/larsxschneider/git/commit/faf4ecfdca1a732459c1f93c334928ee2826d490\n\nThat's promising!\n\n> - Lars\n"}]}