felipecrv commented on code in PR #37877:
URL: https://github.com/apache/arrow/pull/37877#discussion_r1342745111


##########
docs/source/format/Columnar.rst:
##########
@@ -487,6 +499,102 @@ will be represented as follows: ::
           |-------------------------------|-----------------------|
           | 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 | unspecified (padding) |
 
+ListView Layout
+~~~~~~~~~~~~~~~
+
+The ListView layout is defined by three buffers: a validity bitmap, an offsets
+buffer, and an additional sizes buffer. Sizes and offsets have the identical 
bit
+width and both 32-bit and 64-bit signed integer options are supported.
+
+As in the List layout, the offsets encode the start position of each slot in 
the
+child array. In contrast to the List layout, list lengths are stored explicitly
+in the sizes buffer instead of inferred. This allows offsets to be out of 
order.
+Elements of the child array do not have to be stored in the same order they
+logically appear in the list elements of the parent array.
+
+When a value is null, the corresponding offset and size can have arbitrary
+values. When size is 0, the corresponding offset can have an arbitrary value.

Review Comment:
   My intention here is to say that an implementation that trusts `offsets[i]` 
when `sizes[i] == 0` is non-compliant and unsafe. I consider that being more 
strict on what consumers of list-views can do than saying "go ahead and feel 
free to dereference any offset". Being stricter on producers of list-views 
doesn't make the consumers protected from malicious or bogus producers.
   
   > ...and perhaps specific instrumentations such as ASan / UBsan.
   
   Being able to pass random list-view arrays with wild `offsets[i]` when 
`sizes[i] == 0` is how we can fuzz the implementations and get ASan / UBSan to 
catch the mistakes. Well-behaved `offsets[i]` will more likely hide issues than 
highlight them.
   



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