Buggy drivers that keep returning empty strings in SQLGetData can get PDO_ODBC stuck in a loop

[NattyNarwhal]

Happened in PHP 8.4.15.

The driver here is being quite silly. Not sure why it decided to do it for this data (and did so in a reproducible manner, without a workaround). unixODBC trace when it happens:

[...getting the column in chunks]
[ODBC][286773][1774288047.961549][SQLGetData.c][237]
		Entry:
			Statement = 180ad0570
			Column Number = 1
			Target Type = 1 SQL_CHAR
			Buffer Length = 256
			Target Value = 70000000007c600
			StrLen Or Ind = 70000000008b190
[ODBC][286773][1774288047.961640][SQLGetData.c][545]
		Exit:[SQL_SUCCESS_WITH_INFO]                
			Buffer = Indicator = -4                
			Strlen Or Ind = 70000000008b190 -> -4 (64 bits)
[ODBC][286773][1774288047.961671][SQLGetData.c][237]
		Entry:
			Statement = 180ad0570
			Column Number = 1
			Target Type = 1 SQL_CHAR
			Buffer Length = 256
			Target Value = 70000000007c600
			StrLen Or Ind = 70000000008b190
[ODBC][286773][1774288047.961761][SQLGetData.c][545]
		Exit:[SQL_SUCCESS_WITH_INFO]                
			Buffer = Indicator = -4                
			Strlen Or Ind = 70000000008b190 -> -4 (64 bits)
[ODBC][286773][1774288047.961792][SQLGetData.c][237]
		Entry:
			Statement = 180ad0570
			Column Number = 1
			Target Type = 1 SQL_CHAR
			Buffer Length = 256
			Target Value = 70000000007c600
			StrLen Or Ind = 70000000008b190
[ODBC][286773][1774288047.961828][SQLGetData.c][545]
		Exit:[SQL_SUCCESS]                
			Buffer = [<redacted...>]                
			Strlen Or Ind = 70000000008b190 -> 193 (64 bits)
[ODBC][286773][1774288047.961859][SQLGetData.c][237]
		Entry:
			Statement = 180ad0570
			Column Number = 1
			Target Type = 1 SQL_CHAR
			Buffer Length = 256
			Target Value = 70000000007c600
			StrLen Or Ind = 70000000008b190
[ODBC][286773][1774288047.961891][SQLGetData.c][545]
		Exit:[SQL_SUCCESS]                
			Buffer = []                
			Strlen Or Ind = 70000000008b190 -> 0 (64 bits)
[ODBC][286773][1774288047.961921][SQLGetData.c][237]
		Entry:
			Statement = 180ad0570
			Column Number = 1
			Target Type = 1 SQL_CHAR
			Buffer Length = 256
			Target Value = 70000000007c600
			StrLen Or Ind = 70000000008b190
[ODBC][286773][1774288047.961953][SQLGetData.c][545]
		Exit:[SQL_SUCCESS]                
			Buffer = []                
			Strlen Or Ind = 70000000008b190 -> 0 (64 bits)
[ODBC][286773][1774288047.961984][SQLGetData.c][237]
		Entry:
			Statement = 180ad0570
			Column Number = 1
			Target Type = 1 SQL_CHAR
			Buffer Length = 256
			Target Value = 70000000007c600
			StrLen Or Ind = 70000000008b190
[ODBC][286773][1774288047.962016][SQLGetData.c][545]
		Exit:[SQL_SUCCESS]                
			Buffer = []                
			Strlen Or Ind = 70000000008b190 -> 0 (64 bits)
[empty strings forever...]

In this loop, it'll continue to just realloc and copy nothing. (In 8.5, this changes to use a dynamic buffer size, but the logic there is the same.)

[NattyNarwhal]

I have a very simple workaround that only continues if the string isn't empty, and it does seem to fix it for this user. However, it does feel kinda gross, and I'm not entirely certain of impact elsewhere.

diff --git a/ext/pdo_odbc/odbc_stmt.c b/ext/pdo_odbc/odbc_stmt.c
index ea9d5c788f5..c114f721a7a 100644
--- a/ext/pdo_odbc/odbc_stmt.c
+++ b/ext/pdo_odbc/odbc_stmt.c
@@ -710,7 +710,7 @@ static int odbc_stmt_get_col(pdo_stmt_t *stmt, int colno, zval *result, enum pdo
 					str = zend_string_realloc(str, used + 256, 0);
 					memcpy(ZSTR_VAL(str) + used, buf2, 256);
 					used = used + 255;
-				} else if (rc==SQL_SUCCESS) {
+				} else if (rc == SQL_SUCCESS && C->fetched_len != 0) {
 					str = zend_string_realloc(str, used + C->fetched_len, 0);
 					memcpy(ZSTR_VAL(str) + used, buf2, C->fetched_len);
 					used = used + C->fetched_len;

@SakiTakamachi what do you think?