Files that changed from the base of the PR and between 4907f1b and f19f3e5.

• src/crab/dsl_syntax.hpp (0 hunks)
• src/crab/ebpf_domain.hpp (8 hunks)
• src/crab/interval.hpp (1 hunks)
• src/crab/linear_expression.hpp (4 hunks)
• src/crab_utils/num_big.hpp (1 hunks)
• src/crab_utils/num_extended.hpp (1 hunks)

• src/crab/dsl_syntax.hpp

src/crab_utils/num_extended.hpp (1)

46-46: Verify usage of the new constructor in the codebase.

The new constructor provides a more direct way to construct extended_number from integral types. To ensure it's being used effectively and doesn't introduce any unintended behavior:

1. Check for any existing code that might benefit from this new constructor.
2. Verify that there are no unexpected implicit conversions in the codebase due to this addition.

Run the following script to find potential uses of the new constructor and verify its impact:

src/crab_utils/num_big.hpp (2)

262-262: LGTM: Correct implementation of operator<= for integral types.

The overload is correctly implemented, allowing comparisons between integral types and number_t objects. It maintains consistency with existing comparison operators.

---

262-266: Summary: Good additions enhancing number_t functionality.

These changes improve the number_t class by:

1. Adding comparison capabilities with integral and enum types.
2. Introducing a concept that combines integral types and number_t, useful for future template work.

These additions will make the number_t class more versatile and easier to use in various contexts. The changes are well-implemented and consistent with the existing codebase.

To ensure these changes don't introduce any unintended side effects, please run the following verification script:

This script will help identify any existing code that might be affected by these changes, allowing for necessary adjustments if needed.

✅ Verification successful

Verification Successful: No Conflicting Usages Found

The introduced operator overloads and the finite_integral concept do not conflict with existing code outside of src/crab_utils/num_big.hpp. No unintended side effects were detected.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for any existing usages of operator<= with number_t
# that might be affected by the new overloads.

# Test: Search for existing operator<= usages with number_t
echo "Checking for existing operator<= usages with number_t:"
rg --type cpp "operator<=.*number_t" --glob '!src/crab_utils/num_big.hpp'

# Test: Search for potential usages of the new concept
echo "Checking for potential usages of the finite_integral concept:"
rg --type cpp "finite_integral" --glob '!src/crab_utils/num_big.hpp'

Length of output: 722

src/crab/ebpf_domain.hpp (11)

27-27: LGTM: Constructor signature simplified

The removal of the crab:: namespace prefix from the constructor parameters improves code readability and aligns with the PR's cleanup objective.

---

38-38: LGTM: Improved const-correctness for operator<=

Adding the const qualifier to the operator<= function enhances const-correctness and allows the function to be called on const objects. This is a good practice for member functions that don't modify the object's state.

---

46-48: LGTM: Improved const-correctness and simplified namespace usage

The changes to widen, widening_thresholds, and narrow functions improve const-correctness by adding const qualifiers where appropriate. The removal of the crab:: namespace prefix from thresholds_t is consistent with other changes in the file and simplifies the code.

---

52-52: LGTM: Improved const-correctness for get_loop_count_upper_bound

Adding the const qualifier to the get_loop_count_upper_bound function is appropriate for a getter that doesn't modify the object's state. This change enhances const-correctness and is in line with best practices.

---

56-56: LGTM: Improved const-correctness for to_set

The addition of the const qualifier to the to_set function enhances const-correctness. This is appropriate for a function that doesn't modify the object's state and allows it to be called on const objects.

---

88-88: LGTM: Improved efficiency for initialize_loop_counter

Changing the label_t parameter to a const reference in the initialize_loop_counter function can improve performance by avoiding unnecessary copies. This change aligns with modern C++ practices and the PR's modernization objective.

---

100-105: LGTM: Improved const-correctness for arithmetic and bitwise operations

The addition of const qualifiers to various arithmetic and bitwise operation functions enhances const-correctness. These changes are consistent with the modifications made to other member functions and align with best practices for C++.

---

176-181: LGTM: Improved const-correctness for memory access check functions

The addition of const qualifiers to check_access_stack, check_access_context, check_access_packet, and check_access_shared functions enhances const-correctness. These changes are consistent with the modifications made to other member functions and align with best practices for C++.

---

183-184: LGTM: Improved const-correctness for recompute_stack_numeric_size functions

The addition of const qualifiers to the recompute_stack_numeric_size functions enhances const-correctness. These changes are consistent with the modifications made to other member functions and align with best practices for C++.

---

Line range hint 1-265: Summary: Successful cleanup and modernization

Overall, the changes in this file successfully achieve the PR objectives of cleanup and modernization. The consistent application of const-correctness to member functions and the simplification of namespace usage improve code quality and readability. These changes align well with modern C++ practices.

Key improvements:

1. Enhanced const-correctness across numerous member functions.
2. Simplified namespace usage by removing redundant crab:: prefixes.
3. Minor parameter type updates for improved flexibility and efficiency.

While no major issues were found, it's recommended to verify the implementation of the ashr and add_extra_invariant functions to ensure they correctly handle the updated parameter types.

Great job on improving the code quality!

---

207-212: LGTM with suggestion: Verify implementation of add_extra_invariant

The removal of crab:: namespace prefixes from member variable types and the add_extra_invariant function signature simplifies the code and is consistent with other changes. The addition of the const qualifier to add_extra_invariant improves const-correctness.

Please ensure that the implementation of the add_extra_invariant function correctly handles the const NumAbsDomain& dst parameter, as this change might impact how the function operates on the dst object.

Also applies to: 253-255

✅ Verification successful

Verified: add_extra_invariant Implementation Maintains Const-Correctness

The add_extra_invariant function correctly uses the const qualifier for the dst parameter. Additionally, both has_type and eval_interval methods invoked within the function are properly marked as const, ensuring that no unintended modifications occur.

No further issues were found regarding const-correctness in the implementation.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the implementation of the add_extra_invariant function

# Test: Search for the add_extra_invariant function implementation
echo "Searching for add_extra_invariant function implementation:"
rg --type cpp -A 15 "void\s+add_extra_invariant\s*\("

# Test: Search for calls to the add_extra_invariant function
echo "Searching for calls to add_extra_invariant function:"
rg --type cpp "add_extra_invariant\s*\("

Length of output: 2416

---

Script:

#!/bin/bash
# Description: Verify the implementation of the add_extra_invariant function in ebpf_domain.cpp

# Search for the add_extra_invariant function implementation in ebpf_domain.cpp
echo "Extracting add_extra_invariant implementation:"
rg --type cpp "void\s+ebpf_domain_t::TypeDomain::add_extra_invariant\s*\(" -A 20 src/crab/ebpf_domain.cpp

Length of output: 1435

---

Script:

#!/bin/bash
# Description: Verify that has_type and eval_interval methods in NumAbsDomain are const

# Search for the has_type method declaration in NumAbsDomain
echo "Verifying has_type method is const in NumAbsDomain:"
rg --type cpp "bool\s+has_type\s*\(.*\)\s+const" src/crab/num_abs_domain.hpp

# Search for the eval_interval method declaration in NumAbsDomain
echo "Verifying eval_interval method is const in NumAbsDomain:"
rg --type cpp "interval_t\s+eval_interval\s*\(.*\)\s+const" src/crab/num_abs_domain.hpp

Length of output: 540

---

Script:

#!/bin/bash
# Description: Broadly search for has_type and eval_interval method declarations in NumAbsDomain

# Search for the has_type method declaration within any file in the codebase
echo "Verifying has_type method is const in NumAbsDomain across the codebase:"
rg --type cpp "bool\s+has_type\s*\(.*\)\s+const"

# Search for the eval_interval method declaration within any file in the codebase
echo "Verifying eval_interval method is const in NumAbsDomain across the codebase:"
rg --type cpp "interval_t\s+eval_interval\s*\(.*\)\s+const"

Length of output: 958

src/crab/interval.hpp (1)

59-59: Verify usage and consider refactoring opportunities.

The new constructor provides a convenient way to create intervals from integral types. To fully leverage this addition:

1. Verify that the new constructor is being used where appropriate throughout the codebase.
2. Look for opportunities to simplify existing code by using this constructor instead of more verbose interval creations.

To help with this, you can run the following script to find potential refactoring opportunities:

This script will help identify places where the new constructor could potentially be used to simplify the code.

✅ Verification successful

To address the regex errors, please run the updated scripts below with the --pcre2 flag enabled:

---

Verification successful: No instances of the new constructor found.

The search did not identify any usages of the new interval_t constructor with identical integral arguments or with bound_t. Therefore, no refactoring is necessary at this time.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find potential places to use the new integral constructor

# Search for interval_t construction with two identical integral arguments
rg --type cpp -e 'interval_t\s*\(\s*(\d+)\s*,\s*\1\s*\)' -g '!src/crab/interval.hpp'

# Search for interval_t construction with bound_t and identical integral arguments
rg --type cpp -e 'interval_t\s*\(\s*bound_t\s*\{\s*(\d+)\s*\}\s*,\s*bound_t\s*\{\s*\1\s*\}\s*\)' -g '!src/crab/interval.hpp'

Length of output: 758

---

Script:

#!/bin/bash
# Description: Find potential places to use the new integral constructor with PCRE2 enabled

# Search for interval_t construction with two identical integral arguments
rg --pcre2 --type cpp -e 'interval_t\s*\(\s*(\d+)\s*,\s*\1\s*\)' -g '!src/crab/interval.hpp'

# Search for interval_t construction with bound_t and identical integral arguments
rg --pcre2 --type cpp -e 'interval_t\s*\(\s*bound_t\s*\{\s*(\d+)\s*\}\s*,\s*bound_t\s*\{\s*\1\s*\}\s*\)' -g '!src/crab/interval.hpp'

Length of output: 229

src/crab/linear_expression.hpp (1)

114-114: Ensure proper usage of 'finite_integral' in 'subtract' method

The subtract method signature has been updated:

linear_expression_t subtract(const finite_integral auto& constant) const {

Confirm that finite_integral is the appropriate concept for this parameter and that it does not inadvertently exclude valid types previously supported by number_t. Additionally, ensure all usages of this method are compatible with the new parameter type.

Run the following script to find all invocations of subtract and their argument types:

#!/bin/bash
# Description: Locate all calls to 'subtract' and review argument types.

# Test: Find all usages of 'subtract' with a single argument.
rg --type-add 'cpp:*.cpp' --type cpp 'subtract\(\s*[^\s].*\s*\)' .