-
Notifications
You must be signed in to change notification settings - Fork 601
Consistently use size_t as array count/index in OP_MULTIPARAM
#23645
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
You need to change from |
Oh oops. That code deals with the previous generation, |
7d4e166 to
aa8688e
Compare
|
Fixed that, and also fixed the code in |
|
Visible in the i386 CI, which looks related: If you want to test build locally, I use: on Debian, though you'll need to install some extra packages. (possibly with |
Recently-added code was written largely by copying existing practices in various places. In particular, much of the original code was using `UV` typed variables to store sizes and indexes in various list or array structures, counts of parameters, and so on. On fully 64-bit platforms this is all fine, but on 32-bit platforms with -Duse64bitint enabled, this is a 64-bit integer that won't ever be counting that high. These values might as well be stored as 32-bit integers in that case.
aa8688e to
a100514
Compare
|
The change itself is fine, though it looks like the code in XS::APItest and its tests don't handle/test for Unicode signature parameters. |
|
Mmmm, yes there's not a lot of non-ASCII testing around the code, I find. When I added |
Recently-added code was written largely by copying existing practices in various places. In particular, much of the original code was using
UVtyped variables to store sizes and indexes in various list or array structures, counts of parameters, and so on.On fully 64-bit platforms this is all fine, but on 32-bit platforms with -Duse64bitint enabled, this is a 64-bit integer that won't ever be counting that high. These values might as well be stored as 32-bit integers in that case.