ByteView should be using signed types?

[a10y]

Which part is this question about

Related to the continuation of StringView/BinaryView support in #6163

In arrow_data, the ByteView type is used to encapsulate this structure from the spec:

Notably, the spec dictates that all of these values must be signed integers. However, we're using u32.

The arrow-rs builder for GenericByteViewArray doesn't seem to have any range checks on the block, offset and len values for the view structure, which means, I think, you can happily construct a StringView array with arrow-rs, and then attempt to pass it to PyArrow or Java over IPC and have it fail at runtime.

Describe your question

Should we either

1. be using i32 instead of u32 internally
2. be adding constraints on the builder methods to ensure that we don't allow adding strings > 2GB
3. Has someone noticed this before and addressed it and it's not actually a problem

[alamb]

I think using i32 in the code to conform to the spec makes sense -- arrow normally uses signed integers to allow interop with Java as I understand.

maybe @tustvold or @ariesdevil remembers why we used u32 instead 🤔

[tustvold]

I think the original version of the spec used unsigned which was what the implementation was then based off, I don't see an issue with using i32 or clamping u32