This is an automated email from the ASF dual-hosted git repository.

chaokunyang pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/fury.git


The following commit(s) were added to refs/heads/main by this push:
     new e280b09f test(java): add test for fix of readVarUint36Small behavior 
(#2186)
e280b09f is described below

commit e280b09f259b8142d4e4434cd379256ed034a732
Author: LouShaokun <[email protected]>
AuthorDate: Thu Apr 24 19:47:14 2025 +0800

    test(java): add test for fix of readVarUint36Small behavior (#2186)
    
    <!--
    **Thanks for contributing to Fury.**
    
    **If this is your first time opening a PR on Fury, you can refer to
    
[CONTRIBUTING.md](https://github.com/apache/fury/blob/main/CONTRIBUTING.md).**
    
    Contribution Checklist
    
    - The **Apache Fury (incubating)** community has restrictions on the
    naming of PR titles. You can also find instructions in
    [CONTRIBUTING.md](https://github.com/apache/fury/blob/main/CONTRIBUTING.md).
    - Fury has a strong focus on performance. If the PR you submit will have
    an impact on performance, please benchmark it first and provide the
    benchmark result here.
    -->
    
    ## What does this PR do?
    
    This PR adds a unit test case for the previously fixed bug in the
    `readVarUint36Small()` method (PR #XXXX). The test verifies that the
    method now correctly handles the maximum 36-bit value
    (`0b111111111111111111111111111111111111L`) regardless of whether it's
    read from a buffer with 8 or 9 bytes of remaining space.
    
    The test confirms that:
    1. The fast path (buffer size 9) correctly reads the value
    2. The slow path (buffer size 8) correctly reads the same value
    3. The results from both paths match as expected
    
    ## Related issues
    
    - #2110 [Java] Inconsistent readVarUint36Small() behavior depending on
    remaining buffer size
    
    ## Does this PR introduce any user-facing change?
    
    - [ ] Does this PR introduce any public API change?
    - [ ] Does this PR introduce any binary protocol compatibility change?
    
    ## Benchmark
    
    <!--
    When the PR has an impact on performance (if you don't know whether the
    PR will have an impact on performance, you can submit the PR first, and
    if it will have impact on performance, the code reviewer will explain
    it), be sure to attach benchmark data here.
    -->
---
 .../test/java/org/apache/fury/memory/MemoryBufferTest.java    | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git 
a/java/fury-core/src/test/java/org/apache/fury/memory/MemoryBufferTest.java 
b/java/fury-core/src/test/java/org/apache/fury/memory/MemoryBufferTest.java
index 42728202..a4dd5bd3 100644
--- a/java/fury-core/src/test/java/org/apache/fury/memory/MemoryBufferTest.java
+++ b/java/fury-core/src/test/java/org/apache/fury/memory/MemoryBufferTest.java
@@ -633,6 +633,17 @@ public class MemoryBufferTest {
       buf._unsafePutVarUint36Small(index, 
0b1000000000000000000000000000000000000L);
       assertEquals(buf.readVarUint36Small(), 0); // overflow
     }
+    {
+      // With buffer size 9
+      MemoryBuffer buf1 = MemoryBuffer.newHeapBuffer(9);
+      // With buffer size 8
+      MemoryBuffer buf2 = MemoryBuffer.newHeapBuffer(8);
+      long uint36Max = 0b111111111111111111111111111111111111L;
+      buf1._unsafePutVarUint36Small(0, uint36Max);
+      buf2._unsafePutVarUint36Small(0, uint36Max);
+      assertEquals(buf1.readVarUint36Small(), uint36Max);
+      assertEquals(buf2.readVarUint36Small(), uint36Max);
+    }
   }
 
   @Test


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to