[jira] [Commented] (ARROW-16013) [C++][Python] Signed overflow when using negative stride in NumPyStridedConverter

["David Li (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARROW-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17511464#comment-17511464 ] 

David Li commented on ARROW-16013:
----------------------------------

I'm curious how you got ubsan (and presumably/possibly asan?) to work with a Python build, IIRC, last time I tried, you also needed Python built with ubsan/asan

> [C++][Python] Signed overflow when using negative stride in NumPyStridedConverter
> ---------------------------------------------------------------------------------
>
>                 Key: ARROW-16013
>                 URL: https://issues.apache.org/jira/browse/ARROW-16013
>             Project: Apache Arrow
>          Issue Type: Bug
>          Components: C++, Python
>            Reporter: Tobias Zagorni
>            Assignee: Tobias Zagorni
>            Priority: Minor
>              Labels: pull-request-available
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> The calculation of the stride value passed to {{CopyStridedNatural}} by {{NumPyStridedConverter::Visit}} divides the stride value by sizeof(T), which is unsigned, without an appropriate type case. This causes {{CopyStridedNatural}} to access bogus indices.
> This is triggered by the existing test method {{test_numpy_to_pyarrow}} in {{test_array.py}} (at {{{}pa.array(np_arr[case]){}}}). When using ubsan catches a signed integer overflow, otherwise it apparently does what we want, but is still undefined behavoir.
> Also the existing behavoir would probably not work for data types that are not a power of 2, if such would exist (numpy docs mention a float96 can exist on some platforms, but I don't have them on x86_64)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)