You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It might be, that we are a little bit to strict with the current call resolving.
We always check the parameter types, also for languages where no function overloading exists.
This will not map function calls, where one of the parameters have an UNKNOWN type.
Or we only take the shortcut, when one of the types is unknown. Update: Of course, the number of arguments must match, otherwise something is going wrong.
What do you think?
Independent of the function overloading thing, we could think about, if we want to allow casting from UNKNOWN type to any type to relax and over approximate the function resolution.
It might be, that we are a little bit to strict with the current call resolving.
We always check the parameter types, also for languages where no function overloading exists.
This will not map function calls, where one of the parameters have an
UNKNOWN
type.This is the relevant code part:
cpg/cpg-core/src/main/kotlin/de/fraunhofer/aisec/cpg/ScopeManager.kt
Lines 719 to 731 in fdc642b
Theoretically, for the "not HasFunctionOverloading" case, we could finish here with an
==1
:cpg/cpg-core/src/main/kotlin/de/fraunhofer/aisec/cpg/ScopeManager.kt
Lines 723 to 725 in fdc642b
Or we only take the shortcut, when one of the types is unknown.
Update: Of course, the number of arguments must match, otherwise something is going wrong.
What do you think?
Example where current call resolving fails:
The text was updated successfully, but these errors were encountered: