Skip to content

Conversation

@harveyj1953
Copy link
Contributor

No description provided.

@pcanal
Copy link
Member

pcanal commented Apr 5, 2017

Could you resolve the conflicts?

for (Int_t i = 0; i < nbentries; i++)
h2->Fill(hist->fBuffer[3*i + 2], hist->fBuffer[3*i + 3],hist->fBuffer[3*i + 1] );
if (auto h2 = dynamic_cast<TH2*>(fH0)){
R__ASSERT(h2);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a false positive in coverity, i.e. if h2 is nullptr we will issue a fatal error and abort. The assert in the if-stmt here becomes dead code.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably coverity does not know that you will never comeback from R__ASSERT with a nullptr.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is indeed very likely. Is there a way to teach coverity about the semantic of that macro?

Copy link
Member

@Axel-Naumann Axel-Naumann Apr 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coverity believes that ::Fatal() might return. As a matter of fact I can simply set gAbortLevel to kFatal + 1 and Fatal() will not abort! I.e. indeed and in principle: Coverity is correct here :-)

For all practical purposes though we should annotate Fatal(); see https://coverity.cern.ch/docs/en/cov_checker_ref.html#killpath

I'll take care of it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Told Coverity about Fatal() in 7c8286d - that should get rid if this "defect".

for (Int_t i = 0; i < nbentries; i++)
h3->Fill(hist->fBuffer[4*i + 2], hist->fBuffer[4*i + 3],hist->fBuffer[4*i + 4], hist->fBuffer[4*i + 1] );
if (auto h3 = dynamic_cast<TH3*>(fH0)){
R__ASSERT(h3);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise.

@peremato
Copy link
Contributor

peremato commented Apr 7, 2017

@phsft-bot build

@phsft-bot
Copy link

Starting build on centos7/gcc49, mac1011/native, slc6/gcc49, slc6/gcc62, ubuntu14/native and CMake flags -Dccache=ON -Dimt=OFF

@peremato
Copy link
Contributor

peremato commented Apr 9, 2017

@phsft-bot build

@phsft-bot
Copy link

Starting build on centos7/gcc49, mac1011/native, slc6/gcc49, slc6/gcc62, ubuntu14/native and CMake flags -Dccache=ON -Dimt=OFF

@peremato peremato merged commit f361547 into root-project:master Apr 9, 2017
@peremato
Copy link
Contributor

peremato commented Apr 9, 2017

One failure of the system in one cell.

Float_t xcoord[n], ycoord[n];
for ( double xi = 0; xi < 10.01; xi += 0.2) {

for ( i = 0; i < 50; ++i) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, was it intentional to increment i twice: once in the loop and once in the loop's body (see last line).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand these changes too. The old code looked perfectly fine to me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants