rootvector2 opened a new pull request, #432:
URL: https://github.com/apache/commons-beanutils/pull/432
`getIndex` parses the subscript with `Integer.parseInt` and returns it
unvalidated, but the same method uses `-1` as its documented "not indexed"
sentinel, so `getIndex("stringArray[-1]")` is indistinguishable from
`getIndex("stringArray")` and `getIndex("stringArray[-7]")` hands the caller a
negative subscript. `PropertyUtilsBean.getIndexedProperty`/`setIndexedProperty`
are unaffected because they have their own `index < 0` guard, but the three
callers that branch on `index >= 0` fall through to the non-indexed path and
write the whole property instead of one element. `BeanUtils.copyProperty(bean,
"stringArray[-1]", "x")` and `LocaleBeanUtils.setProperty(bean,
"stringArray[-1]", "x")` both replace a five-element `String[]` with `["x"]`
and throw nothing, while `BeanUtils.setProperty` and
`PropertyUtils.setIndexedProperty` reject the same expression. Found while
auditing `DefaultResolver` against its call sites after noticing `getIndex` can
return a value that collides with its ow
n sentinel.
Indexes are zero-relative, so a negative subscript is rejected in `getIndex`
with the same `IllegalArgumentException` it already throws for a non-numeric
one. Keeping the check where the subscript is parsed covers all five call sites
at once, and `DefaultResolver` is the only `Resolver` implementation. No
existing test used a negative index; the new assertions in
`DefaultResolverTest.testGetIndex` fail without the runtime change.
- [x] Read the [contribution guidelines](CONTRIBUTING.md) for this project.
- [ ] Read the [ASF Generative Tooling
Guidance](https://www.apache.org/legal/generative-tooling.html) if you use
Artificial Intelligence (AI).
- [ ] I used AI to create any part of, or all of, this pull request. Which
AI tool was used to create this pull request, and to what extent did it
contribute?
- [x] Run a successful build using the default
[Maven](https://maven.apache.org/) goal with `mvn`; that's `mvn` on the command
line by itself.
- [x] Write unit tests that match behavioral changes, where the tests fail
if the changes to the runtime are not applied. This may not always be possible,
but it is a best practice.
- [x] Write a pull request description that is detailed enough to understand
what the pull request does, how, and why.
- [x] Each commit in the pull request should have a meaningful subject line
and body. Note that a maintainer may squash commits during the merge process.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
