SAY-5 commented on issue #68: URL: https://github.com/apache/arrow-go/issues/68#issuecomment-4376546752
Cross-checked main: `String.Value` (`arrow/array/string.go`) still slices directly into `a.values` (the raw buffer bytes via `unsafe.Pointer`), so the dangling-pointer hazard is unchanged. The same pattern is present in `LargeString.Value`, `Binary.Value`, and `BinaryView.ValueString` — any fix probably wants to be cross-cutting. Before opening a PR, would the maintainers prefer: 1. **Additive copy accessor** (e.g. `ValueCopy(i int) string` returning `string([]byte(a.Value(i)))`) on `String`/`LargeString`/`Binary`/`BinaryView`, with a doc warning on `Value` for cross-buffer-lifetime use cases. Non-breaking; opt-in safety. 2. **Change `Value` to copy** unconditionally, drop the `unsafe` cast in `setData`. Breaking for users relying on zero-copy semantics, but matches @lidavidm's preference in the original report. 3. **String-view type** (`arrow.StringView` or similar) tied to the array's lifetime via a retain. More invasive but lets callers opt into either zero-copy or owned semantics. I have a draft for option 1 (additive `ValueCopy` + regression test that mallocates a buffer, retains the value, releases the buffer, and asserts the copy survives). Happy to send it if option 1 is acceptable, or to wait if @rtadepalli is already working on a different approach. -- 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]
