Skip to content

Fix DECFLOAT conversion for fetch APIs (#1075) - #1076

Merged
bimalkjha merged 2 commits into
ibmdb:masterfrom
Earammak:decfloatissue1075
Sep 30, 2026
Merged

bimalkjha merged 2 commits into
ibmdb:masterfrom
Earammak:decfloatissue1075

Conversation

@Earammak

@Earammak Earammak commented Sep 16, 2026 •

Copy link
Copy Markdown
Collaborator

Fix DECFLOAT bound-column buffer allocation

The issue was caused by allocating the bound-column buffer based on the column display size. In some cases, the display size was insufficient for the DECFLOAT string representation generated by the CLI conversion routines, resulting in fetch failures.

Fix:

  • Use MAX_DECFLOAT_LENGTH to allocate sufficient buffer space for DECFLOAT values.
  • Ensure adequate space for DECFLOAT value conversion during fetch operations.
  • Prevent fetch failures when DECFLOAT values have longer string representations.

@bimalkjha

Copy link
Copy Markdown
Member

What's good

  • Root cause fix is correct. MAX_DECFLOAT_LENGTH (44) is an existing constant already proven correct elsewhere in ibm_db.c:14488 for SQLGetData-based DECFLOAT fetches (sign + 34 digits + decimal point + E + exponent sign + up to 4 exponent digits + NUL ≈ 43). Using it consistently for the SQLBindCol paths too directly addresses issue CLI0111E on fetch of ordinary DECFLOAT values: bound-column buffer sized from precision+3, not display size #1075 (CLI0111E, buffer sized from precision+3 instead of true display length).
  • Both allocation sites relevant to fetch (bind_column_helper for single-row fetch, bind_rowset_columns for rowset/bulk fetch) are covered. Other SQL_DECFLOAT references in the file (ibm_db.c:2758, ibm_db.c:15358) only consume/convert/free the already-bound buffer, so they don't need parallel changes.
  • No duplicate case labels introduced — compiles fine logically.
  • Adds a test exercising boundary-ish DECFLOAT string values (small magnitude, trailing zeros, negative).

Issues to fix before merging

  1. Missing/incomplete expected-output update — will break z/OS native test runs. testfunctions.py's assert_expect routes z/OS native runs (platform.system() == 'z/OS'/'OS/390' and test name in the testCasesIn allowlist, which explicitly includes test_decfloat) to expected_ZOS_ODBC(). That function uses the __ZOS_ODBC_EXPECTED__ block verbatim if present in the file — it does not fall back to __ZOS_EXPECTED__ in that case. The PR only added the 3 new expected lines to the __LUW_EXPECTED__ and __ZOS_EXPECTED__ blocks in test_decfloat.py, but left __ZOS_ODBC_EXPECTED__ unchanged. Since the new test code runs on that config too (DBMS_NAME there won't start with IDS), the captured output will include the 3 new lines while the expected block won't — causing an assertion failure on z/OS native CI/test runs.

    • Fix: add the same 3 lines (#0.005202572, #0.00520257200000000, #-0.001234567890123456) to the __ZOS_ODBC_EXPECTED__ block as well.
    • __IDS_EXPECTED__ and __SYSTEMI_EXPECTED__ are correctly left alone (IDS is explicitly skipped by the new if serverinfo.DBMS_NAME[0:3] != 'IDS' guard, and SYSTEMI's whole expected block is #NA, implying the test doesn't run there at all).
  2. Minor: code duplication. The new SQL_DECFLOAT block in _python_ibm_db_bind_column_helper (~25 lines) is a near-exact copy of the SQL_BIGINT block, differing only in the in_length computation. Not a blocker, but could be simplified by computing in_length per-type first and sharing the alloc/bind/log logic, reducing future maintenance risk (e.g., if the bind-column logic changes, it now must change in two places).

Verdict

Do not merge yet. The C-side fix itself looks correct and safe (reuses a well-established constant, properly scoped to the two buggy allocation sites). However, the test update has a real gap: the __ZOS_ODBC_EXPECTED__ block wasn't updated, which will cause test_decfloat to fail on z/OS native test runs. Ask the author to add the matching 3 lines to that block (and ideally run/verify the z/OS-ODBC test path) before merging.

@bimalkjha

Copy link
Copy Markdown
Member

@Earammak Please address above issues, then we can merge it. Thanks.

@Earammak

Copy link
Copy Markdown
Collaborator Author

Fix DECFLOAT bound-column buffer size and z/OS ODBC expectations
 
Use MAX_DECFLOAT_LENGTH consistently for SQL_DECFLOAT columns bound via
SQLBindCol in _python_ibm_db_bind_column_helper. Merge the SQL_BIGINT and
SQL_DECFLOAT cases to compute in_length based on the column type while
sharing the allocation, binding, and logging logic.
 
Add the missing DECFLOAT boundary-value expected output lines to the
ZOS_ODBC_EXPECTED block in test_decfloat.py so the new assertions
match on z/OS native ODBC test runs.

@bimalkjha
bimalkjha merged commit c8d2001 into ibmdb:master Sep 30, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CLI0111E on fetch of ordinary DECFLOAT values: bound-column buffer sized from precision+3, not display size

2 participants