Archived issue #0033048
Foundation Classes - math_ComputeKronrodPointsAndWeights indexation goes beyond the limit
Description
This issue is found during studying the results of CppCheck (#0033024).
The following block is invalid:
Standard_Integer aNd2 = Number/2;
Standard_Real *s = new Standard_Real[aNd2 + 2];
Standard_Real *t = new Standard_Real[aNd2 + 2];
Standard_Real *ss = s++;
Standard_Real *tt = t++;
for (i = -1; i <= aNd2; i++) {
s[i] = 0.;
t[i] = 0.;
}
Here, memory is allocated manually without usage of smart pointers (welcome memleaks!) and value is assigned to index -1 that is outside the allowed boundaries [0, aNd2 + 1]. Analysis shows that this class is passed to math::KronrodPointsAndWeights as alternative method of Kronrod poitns and weights calculation for high indices but it seems to be not used.
One should pick one of the following options:
1. Get rid of suspicious class.
2. Identify & fix all the issues, write tests to cover this functionality
_______________________________________________________________________
Analysis revealed that algorithm is OK, and pointer-based raw memory manipulation is correct in this particular case. It is worth adding explanatory comment and test to avoid misunderstanding in future.
The following block is invalid:
Standard_Integer aNd2 = Number/2;
Standard_Real *s = new Standard_Real[aNd2 + 2];
Standard_Real *t = new Standard_Real[aNd2 + 2];
Standard_Real *ss = s++;
Standard_Real *tt = t++;
for (i = -1; i <= aNd2; i++) {
s[i] = 0.;
t[i] = 0.;
}
Here, memory is allocated manually without usage of smart pointers (welcome memleaks!) and value is assigned to index -1 that is outside the allowed boundaries [0, aNd2 + 1]. Analysis shows that this class is passed to math::KronrodPointsAndWeights as alternative method of Kronrod poitns and weights calculation for high indices but it seems to be not used.
One should pick one of the following options:
1. Get rid of suspicious class.
2. Identify & fix all the issues, write tests to cover this functionality
_______________________________________________________________________
Analysis revealed that algorithm is OK, and pointer-based raw memory manipulation is correct in this particular case. It is worth adding explanatory comment and test to avoid misunderstanding in future.
Steps to reproduce
N/A
Public activity
14 archived notes
Participants are labeled by their role within this record.
Branch [archived branch] has been created by Author.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Jul 1 09:10:38 2022 +0300
0033048: Foundation Classes - math_ComputeKronrodPointsAndWeights indexation go beyond the limit
Remove non-used math_ComputeKronrodPointsAndWeights class.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Jul 1 09:10:38 2022 +0300
0033048: Foundation Classes - math_ComputeKronrodPointsAndWeights indexation go beyond the limit
Remove non-used math_ComputeKronrodPointsAndWeights class.
Dear Artem,
It seems this functionality is not used in our tests. Could you please invite IFV and MSV into the discussion?
From my point of view, we should remove this class.
It seems this functionality is not used in our tests. Could you please invite IFV and MSV into the discussion?
From my point of view, we should remove this class.
Alexander,
I propose to implement a specific test case, which covers math_ComputeKronrodPointsAndWeights functionality.
I propose to implement a specific test case, which covers math_ComputeKronrodPointsAndWeights functionality.
Alexander,
IFV found the DRAW command, which calls the inquiring functionality:
Hope, this could help you in writing test cases.
IFV found the DRAW command, which calls the inquiring functionality:
vpropsgk : vpropsgk name epsilon closed span mode [x y z] [-skip] : compute volumic properties
Hope, this could help you in writing test cases.
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Analysis revealed that algorithm is OK, and pointer-based raw memory manipulation is correct in this particular case. It is worth adding explanatory comment and test to avoid misunderstanding in future.
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Artem,
Could you please take a look at the CR33048 branch?
- Explanatory comment is added.
- Test case is added.
Could you please take a look at the CR33048 branch?
- Explanatory comment is added.
- Test case is added.
Branches for integration:
OCCT: CR33048
Products: NO
OCCT: CR33048
Products: NO
Combination -
OCCT branch : [archived branch]
master SHA - changes and them, and you can discard any commits you make in this
[revision removed]
changes and them, and you can discard any commits you make in this
[revision removed]
Products branch : [archived branch] SHA - [revision removed]
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.
Number of compiler warnings:
No new/fixed warnings
Regressions/Differences/Improvements:
No regressions/differences
CPU differences:
Debian80-64:
OCCT
Total CPU difference: 18685.930000000586 / 18908.870000000694 [-1.18%]
Products
Total CPU difference: 11796.890000000125 / 11832.130000000114 [-0.30%]
Windows-64-VC14:
OCCT
Total CPU difference: 20784.828125 / 20752.59375 [+0.16%]
Products
Total CPU difference: 13361.3125 / 13368.90625 [-0.06%]
Image differences :
No differences that require special attention
Memory differences :
No differences that require special attention
OCCT branch : [archived branch]
master SHA - changes and them, and you can discard any commits you make in this
[revision removed]
changes and them, and you can discard any commits you make in this
[revision removed]
Products branch : [archived branch] SHA - [revision removed]
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.
Number of compiler warnings:
No new/fixed warnings
Regressions/Differences/Improvements:
No regressions/differences
CPU differences:
Debian80-64:
OCCT
Total CPU difference: 18685.930000000586 / 18908.870000000694 [-1.18%]
Products
Total CPU difference: 11796.890000000125 / 11832.130000000114 [-0.30%]
Windows-64-VC14:
OCCT
Total CPU difference: 20784.828125 / 20752.59375 [+0.16%]
Products
Total CPU difference: 13361.3125 / 13368.90625 [-0.06%]
Image differences :
No differences that require special attention
Memory differences :
No differences that require special attention
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Related records