OCP seems to generate wrong function signature for array arguments
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by comparing the OCCT HLRAlgo::InitMinMax declaration with the generated OCP.HLRAlgo.HLRAlgo.InitMinMax_s signature. Inspect the binding-generation path for array arguments and use this entry point to reproduce the crash. Done means array arguments are supported correctly, or the generated function rejects them safely instead of accepting an invalid signature.
Written by the indexing model from the issue text.
Description
OCP seems to generate wrong function signature for array arguments.
For example, OCCT has:
void HLRAlgo::InitMinMax (const Standard_Real Big, Standard_Real Min[16], Standard_Real Max[16])
But OCP lists OCP.HLRAlgo.HLRAlgo.InitMinMax_s() as:
TypeError: InitMinMax_s(): incompatible function arguments. The following argument types are supported:
1. (Big: float, Min: float, Max: float) -> None
Of course, if you actually try calling it with just float, it crashes:
>>> from OCP.HLRAlgo import HLRAlgo
>>> HLRAlgo.InitMinMax_s(0., 0., 0.)
*** stack smashing detected ***: terminated
Aborted
I'm not sure if there are any array-argument-taking functions which are likely to be used by anyone (I was only trying to use the MinMax things in HLR to verify I've understood some code correctly, not for actual work); Grepping does indicate that they are used at least in a few other places, but I don't know if those are things that anyone is likely to want to use.
What I'm saying is, I'm not sure if this is "worth" fixing properly (ie. adding support for array arguments), and how hard that would be to do - but if it's decided that it's not worth fixing properly, maybe the functions could at least be made to raise an error when called, instead of actually allowing the call with the wrong signature to go through and crash the program?
- Dominant language
- C++
- Stars
- 203
- Forks
- 50
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CadQuery/OCP
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
Difficulty 3/5 1-2 days Newbie friendliness 58/100
-
Python 3.14t buildOpen
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
OCCT8
Difficulty 3/5 1-2 days Newbie friendliness 35/100
Similar issues
-
HasBacktrace Priority-Critical
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
azerothcore/azerothcore-wotlk#27921 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
yhirose/cpp-peglib#344 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
ExpressLRS/ExpressLRS#3805 ·
Maintainers usually reply within 2 days