Welcome! Please see the About page for a little more info on how this works.

+4 votes
in Collections by
edited by

Is this expected behavior?

clj
Clojure 1.10.3
user=> (get [1 2 42] 4294967295)
nil
user=> (get [1 2 42] 4294967296)
1
user=> (get [1 2 42] 4294967297)
2
user=> (get [1 2 42] 4294967298)
42
user=> (assoc [1 2 42] 4294967298 :wow)
[1 2 :wow]
user=> (find [1 2 42] 4294967298)
[4294967298 42]
user=> (.intValue 4294967298)
2

(Note this is with Clojure 1.10.3, but the syntax highlighting seems to truncate the last part).

AFAICT the get is related to this line in APersistentVector. The other two are caused by similar surrounding lines.

2 Answers

0 votes
by
selected by
 
Best answer

Java collection interfaces are int-indexed (max count = 2147483647). Generally if you have more than 2 billion items in your collection, you might have other problems.

I'd say behavior of indices outside range (0 Integer/MAX_VALUE) is undefined.

by
Agreed, but there's only 3 items in this collection, so perhaps the premise of this conventional wisdom doesn't hold here? (response to the first sentence)
by
Ok, thanks for considering!
by
FWIW there is similar behavior for strings/arrays:

Clojure 1.10.3
user=> (get (into-array [1 2 42]) 4294967296)
1
user=> (get "123" 4294967296)
\1
user=> (get (into-array [1 2 42]) 4294967296 :not-found)
1
user=> (get "123" 4294967296 :not-found)
\1
+5 votes
by
edited by

I believe this report can lead to more serious issues in codebases specially because no warnings are given in the docstrings of get for example.

IMO the following idioms are very common in the community:

(get [1 2 3] 5)
;;=> nil

(get [1 2 3] 5 100)
;;=> 100

And if the value 5 above is user-provided or a result of some math operation that can go wrong, we will cause hard to find bugs or even security breaches.

This form of Index Overflow errors can cause all sorts of problems, this CVE has some concerns about such cases https://cwe.mitre.org/data/definitions/129.html.

I know this is not exactly the same problem, but I share the views of this entry as applicable to our case here:

Scope:
Confidentiality
Integrity

"Use of an index that is outside the bounds of an array can also trigger out-of-bounds read or write operations, or operations on the wrong objects; i.e., "buffer overflows" are not always the result. This may result in the exposure or modification of sensitive data."

I would expect to keep the nil value as answer when accessing an ARRAY using indexes outside its bounds.

...