Panic on CHAR Columns with Special Characters (UTF-8 Encoding)

[MohankrishnaKonuru]

Issue:
Our service panics with slice bounds out of range [:-4] when reading CHAR columns that contain special characters from DB2. The panic originates in the third-party alexbrainman/odbc library (column.go:259, BindableColumn.Value) and propagates through database/sql.(*Rows).Next up to our DefaultDBQueryHandler.readRows in adapter_odbc.go:174.
Root Cause:
The issue is triggered when the DSN is configured with UTF-8 encoding. The ODBC library appears to miscalculate buffer/slice bounds when decoding multi-byte UTF-8 characters stored in fixed-length CHAR columns, resulting in a negative slice index.
Current Workaround:
Removing the UTF-8 encoding parameter from the DSN eliminates the panic. However, this is not a viable long-term solution since we require UTF-8 support for proper character handling.
What We Need:
A solution that preserves UTF-8 encoding in the DSN while preventing the panic. Possible directions include patching or forking the alexbrainman/odbc library to handle multi-byte characters safely in fixed-length columns, adding a recovery mechanism in our adapter layer, or evaluating an alternative DB2 driver.

[alexbrainman]

Hello @MohankrishnaKonuru

I do not understand why you created the issue.

Do you need help debugging your problem?

Alex

[MohankrishnaKonuru]

Hello @MohankrishnaKonuru

I do not understand why you created the issue.

Do you need help debugging your problem?

Alex

Hello Alex,
Thanks for your response. Let me explain the issue in detail.

Environment: We connect to DB2 on IBM i (AS/400) via ODBC with UTF-8 encoding configured in the DSN.

Problem: When fetching a CHAR column that contains special characters, the driver panics with slice bounds out of range [:-4] at column.go:259 inside BindableColumn.Value():
goreturn c.BaseColumn.Value(c.Buffer[:c.Len]) // c.Len becomes -4

Root Cause: With UTF-8 encoding enabled, the ODBC driver converts EBCDIC CHAR data to UTF-8 during fetch. Multi-byte special characters can expand beyond the pre-allocated buffer size in BindableColumn. The length indicator c.Len ends up with an invalid negative value, causing the panic. Without UTF-8 encoding in the DSN, the issue does not occur.

Proposed Solution: We'd like to propose a DSN-level opt-in flag (e.g. SAFE_CHAR_ENCODING=1) that, when present, makes NewVariableWidthColumn return a NonBindableColumn for SQL_C_CHAR and SQL_C_WCHAR types instead of a BindableColumn. The NonBindableColumn path uses SQLGetData with dynamic buffering, which safely handles encoding expansion. The flag would be off by default, so existing behavior is fully preserved.

We are happy to contribute a PR for this if you think this approach is reasonable. Would you be open to it, or do you see a better way to handle this?

[MohankrishnaKonuru]

@alexbrainman - Any update on our request please