Jefffrey commented on code in PR #10510:
URL: https://github.com/apache/arrow-rs/pull/10510#discussion_r3697696950


##########
arrow-cast/src/cast/mod.rs:
##########
@@ -7634,6 +7634,53 @@ mod tests {
         assert_eq!(casted_binary_array.as_ref(), &binary_view_array);
     }
 
+    #[test]
+    fn test_dict_to_view_null_dictionary_value_is_null() {
+        // A null *value* in the dictionary must produce a null row, not the 
empty slice that
+        // its offsets happen to span. `unpack_dictionary`, which serves every 
other target
+        // type, and `impl From<&GenericByteArray> for GenericByteViewArray` 
both produce null
+        // here, so the view output previously disagreed with every other path.

Review Comment:
   ```suggestion
           // Ensure we preserve nulls in the values
   ```
   
   can keep this short and simple



##########
arrow-cast/src/cast/dictionary.rs:
##########
@@ -141,9 +143,24 @@ fn view_from_dict_values<K: ArrowDictionaryKeyType, V: 
ByteArrayType, T: ByteVie
                     ArrowError::ComputeError("Invalid dictionary 
index".to_string())
                 })?;
 
+                // A dictionary built without validation can carry a key past 
the end of the
+                // values. Reject it rather than reading out of bounds below.
+                if idx >= values.len() {
+                    return Err(ArrowError::InvalidArgumentError(format!(
+                        "Dictionary key {idx} out of bounds for dictionary 
values of length {}",
+                        values.len()
+                    )));
+                }
+

Review Comment:
   if a dictionary was built without validation and was incorrect i dont think 
we need to account for this; it means it already didnt uphold its safety 
invariant
   
   however if this can be reached without unsafe that would be something we 
need to fix



-- 
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]

Reply via email to