ProgramMemory: avoid duplicated lookups / removed `at()`

[firewave]

all at() calls were proceeded by hasValue() so we can just directly fetch the value instead.

[firewave]

"impossible" lookups with no exprid will be dealt with in a different PR.

[firewave]

It appears to not have much impact on performance but it gets rid of the at() which has irked me for quite a while.

[firewave]

Should be done but I am seeing slightly less executions when profiling this, which should not be happening since it does not functionally change. So still needs looking into.

[firewave]

Should be done but I am seeing slightly less executions when profiling this, which should not be happening since it does not functionally change. So still needs looking into.

There is indeed a behavior change introduced by this - #7800 surfaced a difference the tests did not catch:

--- selfcheck.exp       2025-09-15 07:19:01.345202904 +0200
+++ selfcheck.res       2025-09-15 07:21:07.006911439 +0200
@@ -13626,6 +13626,8 @@
   tok2 possible symbolic=(tok->next)
 Line 2108
   true always 1
+Line 2109
+  . possible symbolic=(tok2)
 Line 2112
   & {lifetime[Address]=(temp),!0}
 Line 2113

[firewave]

There is indeed a behavior change introduced by this - #7800 surfaced a difference the tests did not catch:

I missed that getValue() does not return impossible values by default where hasValue() and at() do.

[firewave]

I missed that getValue() does not return impossible values by default where hasValue() and at() do.

I consistently added a parameter to the getter (even though they might not be used - can be cleaned up later) and flipped one default.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[firewave]

Should be done but I am seeing slightly less executions when profiling this, which should not be happening since it does not functionally change. So still needs looking into.

There is indeed a behavior change introduced by this - #7800 surfaced a difference the tests did not catch:

--- selfcheck.exp       2025-09-15 07:19:01.345202904 +0200
+++ selfcheck.res       2025-09-15 07:21:07.006911439 +0200
@@ -13626,6 +13626,8 @@
   tok2 possible symbolic=(tok->next)
 Line 2108
   true always 1
+Line 2109
+  . possible symbolic=(tok2)
 Line 2112
   & {lifetime[Address]=(temp),!0}
 Line 2113

I need to reproduce my mistake and add a test which causes this but that will probably take quite a while. Also making it more problematic is that I need to do it on an older commit because another change has also caused this change in the ValueFlow.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud