zeroshade opened a new pull request, #862:
URL: https://github.com/apache/arrow-go/pull/862

   ### Rationale for this change
   
   The safe `decimal128`/`decimal256` → integer cast kernel range-checks each 
value against the output type's bounds before truncating to the low 64 bits. 
The upper-bound check used `value >= max`, where `max` is the *inclusive* 
maximum of the output integer type (e.g. `math.MaxInt64` for `int64`, computed 
via `MaxOf[T]()`). As a result a value exactly equal to the type maximum was 
incorrectly rejected as "integer value out of bounds", even though it is a 
valid in-range value. This affects every integer output type 
(`int8`/`int16`/`int32`/`int64` and the unsigned variants), not just `int64`.
   
   This was noticed while working around the behavior downstream in the ADBC 
Snowflake driver (adbc-drivers/snowflake#161), where it was suggested to fix it 
upstream here.
   
   ### What changes are included in this PR?
   
   - In `decimalToIntImpl` (`arrow/compute/internal/kernels/numeric_cast.go`), 
change the upper-bound overflow check from `value >= max` to `value > max` so 
the inclusive maximum is accepted, matching the already-inclusive lower-bound 
check (`value < min`). The `decimal[T]` helper interface now requires `Greater` 
instead of `GreaterEqual`; both `decimal128.Num` and `decimal256.Num` already 
implement it.
   
   ### Are these changes tested?
   
   Yes. Added an `int64 bounds inclusive` regression subtest to 
`TestDecimal128ToInt` and `TestDecimal256ToInt` that assert, with 
`AllowIntOverflow=false`:
   - `math.MaxInt64` (`9223372036854775807`) and `math.MinInt64` 
(`-9223372036854775808`) cast successfully, and
   - values one beyond either bound still fail as overflow.
   
   `go test ./arrow/compute/...` passes and `go vet` is clean.
   
   ### Are there any user-facing changes?
   
   Yes — a bug fix. A safe (non-`AllowIntOverflow`) decimal→integer cast of a 
value equal to the destination type's maximum (e.g. `math.MaxInt64`) now 
succeeds instead of returning an `ErrInvalid` "integer value out of bounds" 
error. Values genuinely outside the range still error as before.
   


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