Hello @MathiasVP , thank you again for your answer !

While I do understand that tracking references is computationally expensive because it requires additional data structure that stores all references to a variable (I've wrote predicate that reproduce dataflow considering references in local scope with an implicit creation of path using recursive predicate that navigate one ControlFlowNode at a time, and it wasn't pretty even though it worked), and that it's somewhat easier to find reference argument, I'm still a little confuse to why this isn't considered as a barrier.

The fact that CodeQL found the re-assignment inside the function means that it must have reach it while navigating through the Control Flow Graph, and thus it knows (for (I suppose) barely no computational cost) that it is not inside a conditional statement (that is to say, the basic bloc which contains ref = valid; will always be executed). Thus I expected to work correctly the same way that in the following code, only ticC flows to the sink. Am I mistaken in the idea that Dataflow library explore path in the Node graph ?

 ptr = &ticB;
 ptr = nullptr;
 ptr = &ticC;
 ptr->triggerSinkPtr();

Also, I found something quite inconsistent that I cannot explain rationnaly. As pointers and references are more or less the same thing (actually I don't know much about it) I expected to get the same result with CodeQL dataflow whether I use pointers or references. And indeed, modifying a value in local scope by creating a pointer to it isn't detected, the same way that declaring a reference in a local scope and changing it isn't detected as you explained CodeQL doesn't consider alias.

But then, I tried this :

void ptrSetMultipleValid(TwoIntClass** pptr){
 *pptr = nullptr;
 *pptr = new TwoIntClass(1,2);
 *pptr = new TwoIntClass(3,4);
}
void adv_ptr_arg_good(){
 TwoIntClass* ptr = nullptr;
 ptrSetMultipleValid(&ptr);
 ptr->triggerSinkPtr();
 free(ptr);
}

image

However :

void setToMultipleValid(TwoIntClass*& ref){
 TwoIntClass* valid;
 valid = nullptr;
 valid = new TwoIntClass{1,2}; //incidental memory leak
 valid = new TwoIntClass{3,4};
 ref = valid;
}
void adv_ref_arg_good(){
 TwoIntClass* ptr = nullptr;
 setToMultipleValid(ptr);
 ptr->triggerSinkPtr();
 free(ptr);
}

image

When passing a pointer to a pointer in argument :

• the initially assigned nullptr is detected (which make sens from your explanation)
• All assignment to the dereferenced pptr are detected : nullptr / new TwoIntClass(1,2) / new TwoIntClass(3,4) Which I can also make sens of because indeed if there where conditional branching in ptrSetMultipleValid we aren't able to guarantee which one are executed.

However, when passing a reference argument :

• the initially assigned nullptr is detected (same as before)
• however, only the last new TwoIntClass{3,4} is detected ! And the assignment valid = nullptr; and valid = new TwoIntClass{1,2} are correctly ignored

(I wondered if this was because of the intermediate ref = valid; ? I just tested and this has in fact nothing to do with the intermediate ref=valid, so this prove that reference arguments and pointer arguments are handle differently by CodeQL. As they're basically the same I don't see why they should be treated differently)

void setToMultipleValidBIS(TwoIntClass*& ref){
 cout << "seting ptr to a valid value, no intermediate"<<endl;
 ref = nullptr;
 ref = new TwoIntClass{1,2}; //incidental memory leak
 ref = new TwoIntClass{3,4};
}
void adv_ref_arg_goodBIS(){
 TwoIntClass* ptr = nullptr;
 setToMultipleValidBIS(ptr);
 ptr->triggerSinkPtr();
 free(ptr);
}

image

(only the latest / guaranteed execution ref = new TwoIntClass(3,4) is detected to flow to the sink.

I will now run some test about conditional branching, any key concept I should keep in mind before trying ?