OCP seems to generate wrong function signature for array arguments
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Bắt đầu bằng cách so sánh khai báo OCCT HLRAlgo::InitMinMax với chữ ký OCP.HLRAlgo.HLRAlgo.InitMinMax_s được tạo ra. Kiểm tra đường dẫn tạo binding cho các đối số mảng và sử dụng entry point này để tái hiện sự cố crash. Hoàn thành khi các đối số mảng được hỗ trợ đúng cách, hoặc hàm được tạo ra từ chối chúng một cách an toàn thay vì chấp nhận một chữ ký không hợp lệ.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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?
- Ngôn ngữ chính
- C++
- Star
- 205
- Fork
- 50
- Merge trung bình
- 3 ngày 4 giờ
- Pull request đã merge (30 ngày)
- 1
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của CadQuery/OCP
-
Generation steps fails when OPENGL_INCLUDE_DIRS is a listCó thể đã có người làm @adam-urbanczyk đã nhận 73 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 58/100
-
Python 3.14t buildĐang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Issue tương tự
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Mac mini M6 (16 GB): Q2_0 streaming works - measured 11.7->27.2 tok/s + arena fix for sub-32 GB MacsĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
champion good first issue remake source/qq
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
metasequoiaime/msime-windows#1025 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
backlog bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
EchoTools/nevr-runtime#653 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
`--fail-require-skip` never fires: run_tests.py searches stdout, but the unittest binary writes the skip summary to stderrCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày