Fix SQL_C_GUID parameter binding sending corrupted data on the wire (#295)

[fdcastel]

What this fixes

When an ODBC application calls SQLBindParameter(SQL_C_GUID, SQL_GUID, …, ptr, 16, &len) and hands the driver a 16-byte UUID, the driver returns SQL_SUCCESS but Firebird never sees the 16 UUID bytes:

• BINARY(16) / CHAR(16) CHARACTER SET OCTETS target — Firebird stores the ASCII bytes of the first 16 chars of the canonical UUID string (30 33 30 36 43 31 37 36 2D 45 34 30 31 2D 31 31 instead of the 16 raw UUID bytes).
• Text target (e.g. CHAR_TO_UUID(?)) under CHARSET=UTF8 — Firebird returns expression evaluation not supported — Human readable UUID argument for CHAR_TO_UUID must have hex digit at position 2 instead of "".

Reproducers, both from issue #295:

-- Reproducer A: parameter described as CHAR(16) CHARACTER SET OCTETS
SELECT UUID_TO_CHAR(?) FROM rdb$database
--   Expected: 'A0EEBC99-9C0B-4EF8-BB6D-6BB9BD380A11'
--   Actual:   '41304545-4243-3939-2D39-4330422D3445' (ASCII of the truncated string)

-- Reproducer B: parameter described as CHAR(36) in the connection charset
SELECT UUID_TO_CHAR(CHAR_TO_UUID(?)) FROM rdb$database
--   Expected: 'A0EEBC99-9C0B-4EF8-BB6D-6BB9BD380A11'
--   Actual:   HY000(-833) "must have hex digit at position 2 instead of ''"

Real-world impact: duckdb/odbc-scanner binds DuckDB ::UUID values exactly this way (see src/types/uuid_type.cpp L33-44). Their Firebird UUID round-trip test (duckdb/odbc-scanner#169) is parked on this.

Closes #295.

Root cause

• Reproducer A. The driver stringified the GUID into the 16-byte OCTETS slot. On Windows snprintf is _snprintf (see OdbcJdbc.h), which truncates and returns -1; the legacy len == -1 line then reported 16 bytes, so Firebird stored the ASCII of the first 16 chars.
• Reproducer B. With CHARSET=UTF8 Firebird describes the ? in CHAR_TO_UUID(?) as CHAR(36) UTF8, 144 bytes. The driver maps UTF8 text to JDBC_WCHAR, so the dispatch picked convGuidToStringW and wrote UTF-16 onto the wire. Firebird saw A, NUL, 0, NUL, … hence "hex digit at position 2". With CHARSET=NONE the slot is CHAR(36) ASCII and the old code passed on Windows by accident (36 chars fit _snprintf exactly, no terminator); C99 snprintf writes 35 chars plus NUL there.

How the fix works

OdbcConvert::getAdressFunction switches on the target type first, like the neighbouring arms. For an input parameter described as CHAR/VARCHAR:

• OCTETS charset (Firebird's BINARY(n) / VARBINARY(n)): convGuidToBinary writes the 16 bytes in canonical UUID byte order (Data1/2/3 big-endian, Data4 as is). A slot shorter than 16 bytes is rejected with 22001.
• Any other charset: convGuidToString stages the 36-char canonical UUID in the DescRecord local buffer and points sqldata at it, the idiom transferStringToAllowedType uses. The wire buffer cannot be written directly: it may be VARYING (length prefix), shorter than 36 bytes, or a UTF8 text the driver maps to SQL_C_WCHAR. setTypeText() makes the slot SQL_TEXT and Sqlda::checkAndRebuild() rebuilds the message for the new length; Firebird reports the truncation itself when the slot is too small.
• Any other target type (INTEGER, DATE, BLOB): 07006, as before. ODBC defines no GUID conversion to those types.

convGuidToString also serves the application-side fetch path (SQLGetData(…, SQL_C_CHAR, …) from a column described as SQL_GUID, dormant until T5-5 / #287 lands); it branches on to->isIndicatorSqlDa only for the destination. convGuidToStringW is unchanged. Both Firebird-side writers use ODBCCONVERT_CHECKNULL_SQLDA, so a value bound after a NULL clears the null flag.

IscHeadSqlVar::isBinary() / isVarBinary() read the dedicated sqlcharset field to identify OCTETS slots.

Tests

GuidParamBindingTest in tests/test_guid_and_binary.cpp:

• BindGuidToCharOctets16, BindGuidToVarcharOctets16 — SQL_C_GUID into CHAR(16) / VARCHAR(16) OCTETS columns, read back via UUID_TO_CHAR.
• BindGuidToUuidToCharRoundtrip, BindGuidToVarcharViaCharToUuid — the two reproducers. The text one fails on the old code only under CHARSET=UTF8 (CI's primary run) or on Linux; the comment in the test says why.
• BindGuidToIntegerParamIsRejected (07006), BindGuidToUndersizedOctetsIsRejected (22001), BindGuidToOversizedOctetsStoresRawBytes (VARBINARY(32) receives 16 bytes), BindGuidValueAfterNull (a value bound after a NULL is sent).

The two VARCHAR OCTETS tests skip on the FB6 snapshot, which aborts parameterized OCTETS-varying statements server-side, the same limitation guarded elsewhere in the suite.

[irodushka]

Honestly, I studied this PR and didn't understand a thing. Could you describe it more clearly—where the error was, how to reproduce it, and what the purpose of these changes was?..

[irodushka]

I understand the code switching for string/binary, it's okay. But what's the purpose of total rewriting of the convGuidToString() foo? And why the convGuidToStringW() is left untouched?..

[fdcastel]

Thanks for the review — fair feedback. I rewrote the commit so the diff is easier to read; here's the walkthrough.

The bug. An ODBC app calls SQLBindParameter(SQL_C_GUID, SQL_GUID, …, ptr, 16, &len) and hands the driver a 16-byte UUID. The driver returns SQL_SUCCESS but Firebird never sees the 16 UUID bytes:

• BINARY(16) / CHAR(16) CHARACTER SET OCTETS target: the bytes Firebird stores are 30 33 30 36 43 31 37 36 2D 45 34 30 31 2D 31 31 — the ASCII characters of the first 16 chars of the canonical UUID string. The driver was stringifying the GUID to 36 chars and then truncating to 16 to fit the column.
• VARCHAR target (e.g. CHAR_TO_UUID(?)): Firebird returns expression evaluation not supported — Human readable UUID argument for CHAR_TO_UUID must have hex digit at position 2 instead of "". The driver was writing a wide-char (UTF-16) buffer into a narrow-char wire slot, so the embedded NULs made the string look empty.

Issue #295 has the full empirical trace including the two reproducers above (SELECT UUID_TO_CHAR(?) and SELECT UUID_TO_CHAR(CHAR_TO_UUID(?))). Real-world impact: duckdb/odbc-scanner binds DuckDB ::UUID values exactly this way, so their Firebird UUID round-trip test (their PR #169) is parked on this.

The fix shape, after the rewrite. convGuidToString and convGuidToStringW are now unchanged — they remain the original short snprintf/swprintf helpers for the app-side fetch path (SQLGetData(…, SQL_C_CHAR/WCHAR, …) from a column described as SQL_GUID). That path is currently dead code because the column-side SQL_GUID mapping is open T5-5, but there's no reason to disturb them.

The wire-side fix lives in two new functions:

• convGuidToBinary — writes 16 bytes in canonical UUID byte order (Data1/2/3 swapped from x86 little-endian to big-endian, Data4 unchanged). Used when the wire is BINARY(16) / CHAR(16) OCTETS, or FB4+ BINARY/VARBINARY.
• convGuidToVarString — stages the 36-char canonical UUID in the DescRecord local buffer and points the wire's sqldata there via setSqlData(). This mirrors the idiom transferStringToAllowedType already uses, and sidesteps the fact that an untyped ? placeholder is described by Firebird as VARCHAR(0) — its wire buffer only has room for the 2-byte length prefix, nowhere near enough for 36 chars.

The dispatch in getAdressFunction routes to the new functions on the wire side (to->isIndicatorSqlDa) and leaves the existing SQL_C_CHAR / SQL_C_WCHAR switch arms alone for the app-output direction.

getSqlSubtype() and getSqlLen() on HeadSqlVar are pure read-only accessors that let the dispatch distinguish sqlsubtype == 1 + sqllen == 16 (= BINARY/CHAR(16) OCTETS, must be raw bytes) from a regular text charset (= must be canonical UUID string).

History is squashed to one commit; force-pushed with --force-with-lease. Happy to split it back out if you'd rather see step-by-step commits.

[fdcastel]

@irodushka Just a friendly ping on this PR when you have a chance. 🙂

This one (ideally together with #292 and #293) feels like a strong candidate for an rc2 release. That would let me finally close out the remaining DuckDB integration issue.

After that, we could get back on track with #287.

[irodushka]

@fdcastel

I'm lost in a tangle of different caliber troubles. Not related to FB or ODBC) Hardly doubt I'll be able to switch to those PRs this week, sorry(

[fdcastel]

No worries. I know the feeling. 😅

Let me know when we can get back on track.

[irodushka]

@fdcastel found some time to throw some shi ideas at your PR)
Please cover the given code with test cases first and only then fix...
Cheers!

[fdcastel]

Took the "cover the code with tests first" advice — and it immediately paid off.

• Added BindGuidToVarcharOctets16 — binds SQL_C_GUID to VARCHAR(16) CHARACTER SET OCTETS (the wire form of native FB4+ VARBINARY(16)). The existing tests only covered the fixed CHAR(16) / SQL_TEXT slot; this is the SQL_VARYING binary wire, which was untested.
• That test exposed a real bug, now fixed. On the varying wire, convGuidToBinary wrote the 16 bytes at offset 0 with no 2-byte VARYING length prefix; Firebird then read the first GUID bytes as a length and over-read the buffer — a hard SEGFAULT on the FB6 snapshot (silently tolerated on FB5). Fix mirrors the text branch: the dispatch now calls setTypeText() for the OCTETS subtype-1/len-16 case so the varying wire becomes fixed SQL_TEXT and the offset-0 write is correct (no-op for an already-fixed CHAR(16) wire).
• Dropped two dead SQL_C_BINARY dispatch arms. Native BINARY/VARBINARY reach the dispatch as OCTETS subtype-1/len-16 (handled above), so the wire-side conciseType == SQL_C_BINARY arm only fired for a binary BLOB; the app-side arm is unreachable until column-side SQL_GUID mapping (T5-5 / [EPIC] vNext Migration Plan #287) lands.

Rebased on current master. CI is green across the matrix. The new VARBINARY test is SKIP_ON_FIREBIRD6-guarded: even with the prefix fix, the FB6 snapshot still aborts this parameterized OCTETS-varying insert with a server-side "Stack overflow" — the same parameterized-query incompatibility already guarded across the suite — so it runs on FB 3/4/5 and skips on FB6.

Whenever you have a moment, a review would be much appreciated 🙏

[irodushka]

Hi @fdcastel

Okay, but the most of my notes (7 to be exact) are still pending...

[fdcastel]

Okay, but the most of my notes (7 to be exact) are still pending...

?

Sorry... What notes?

[irodushka]

These)) didn't commit the review, sorry

[fdcastel]

Pushed 1571a97 addressing all 8 review notes — per-comment responses are on the inline threads below.

Verified locally: clean build (0 warnings), FB 5.0.3 → all 4 GuidParamBindingTest cases pass, FB6 snapshot → 3 pass + BindGuidToVarcharOctets16 skipped per the documented FB6 parameterized-OCTETS-varying limitation (unchanged from 84babbf), full local suite 225 passed, 0 failed. CI green on the full matrix (run 26532371395).

[irodushka]

Aha... Now I got it - there was no separate field for charset in the ISC API, so subtype was used.
But

    inline void bindProperties( Firebird::ThrowStatusWrapper& status, Firebird::IMessageMetadata* _meta, unsigned _index ) {
		index = _index;
		//
		offsetData = _meta->getOffset    ( &status, index );
		offsetNull = _meta->getNullOffset( &status, index );
		isNullable = _meta->isNullable   ( &status, index );
		sqlname    = _meta->getField     ( &status, index );
		relname    = _meta->getRelation  ( &status, index );
		aliasname  = _meta->getAlias     ( &status, index );
		//attention - ooapi may return type+bit if getType() is called from IMetadataBuilder!
		sqltype    = _meta->getType      ( &status, index ) & ~1;
		//
		sqlscale   = _meta->getScale     ( &status, index );
		sqlsubtype = _meta->getSubType   ( &status, index );
		sqlcharset = _meta->getCharSet   ( &status, index );
		sqllen     = _meta->getLength    ( &status, index );

		//OOAPI provides subtype & charset separately
		if (sqltype == SQL_TEXT || sqltype == SQL_VARYING)
		{
			sqlsubtype = sqlcharset;
		}
		//
		++index; //to make it 1-based)

		orgSqlProperties = *this; // save original props
		lastSqlProperties = *this;
	}

and I think it's much more clear to specify sqlvar->sqlcharset == CHARSET_OCTETS; in is(Var)Binary foos.

[fdcastel]

Done in ccbcf93. Switched isBinary() / isVarBinary() to read sqlvar->sqlcharset == CHARSET_OCTETS instead of sqlvar->sqlsubtype. You're right — SqlProperties (IscDbc/Sqlda.h:34-49) carries the charset id in a dedicated field, the comment on sqlsubtype literally says "datatype subtype - BLOBs & Text types only", and CAttrSqlVar::bindProperties (IscDbc/Sqlda.h:115-118) only overlays sqlcharset into sqlsubtype for downstream compatibility. Reading the dedicated sqlcharset field is the semantically right one and removes the "two meanings of sqlsubtype" mental gymnastics entirely. CHARSET_OCTETS is now unsigned to match sqlcharset's declared type, and the helper docstring is rewritten accordingly. Thanks for catching it.

[irodushka]

Hi @fdcastel

about #296 (comment)

All these conv mechanix (OdbcConvert.cpp) is not mine, but I think I understand the initial idea. The switching is going primarily on from type and then - on to type. And it's symmetric and have no need to know the phy direction wire->app or visa versa. All the logic operates with the abstract from and to objs - I mean the (DescRecord * from, DescRecord * to) basic contract. Well, if you need you can obtain the phy direction via the bool DescRecord::isIndicatorSqlDa property, but it may be used for exclusions only.

This approach, primarily fine and solid, subsequently was repeatedly distorted by countless updates & fixes)
But that's just the tip of the iceberg comparing to AI)))) [we Russians say - that's just the flowers, wait for the berries)]

I must think about it))

[fdcastel]

Agreed. That’s the core issue. You're right that the skeleton is "from-then-to": the outer switch (from->conciseType) with an inner switch (to->conciseType) per arm.

On the symmetry point, I leaned on the existing pattern: to->isIndicatorSqlDa is already a primary dispatch axis throughout this function, not just an exclusion. A couple of examples in the current code:

• The NUMERIC arm picks the function pointer by direction, per to type — OdbcConvert.cpp:456-489:

  case SQL_C_SLONG:
      if ( to->isIndicatorSqlDa )
          return &OdbcConvert::convTagNumericToLong;   // wire side
      return &OdbcConvert::convNumericToLong;          // app side

  (same for TINYINT / SHORT / FLOAT / DOUBLE / BIGINT / NUMERIC right there, and the DATE / TIME / TIMESTAMP / BINARY / CHAR / WCHAR arms do the same kind of thing.)

• And the Text arm even hoists a direction check above its to-switch and calls setTypeText() before returning a wire-only helper — OdbcConvert.cpp:723-726:

  if ( to->isIndicatorSqlDa && to->headSqlVarPtr->isReplaceForParamArray() )
  {
      to->headSqlVarPtr->setTypeText();
      return &OdbcConvert::transferArrayStringToAllowedType;
  }
  switch(to->conciseType) // Text

  which is structurally the same move the GUID arm makes.

So the wire-vs-app split (convGuidToString app-side / convGuidToWireString wire-side) mirrors the established conv* vs transfer* split: the transfer* / setSqlData-redirect helpers only ever exist on the isIndicatorSqlDa side and have no app-side branch.

The reason the GUID wire routing can't be expressed as a pure to->conciseType table is that BINARY-vs-text is decided at runtime from the SQLDA state (getSqlLen() == 16 && (isBinary() || isVarBinary())), not from the concise type. And the app-side convGuidToString / convGuidToStringW branch is dormant for now: it only fires once the column-side SQL_GUID mapping lands (T5-5 / #287).

Where I think your instinct is dead on: the GUID arm is the one place that puts if (to->isIndicatorSqlDa) outermost with the to-switch nested in the else, whereas most arms switch on to first and check direction per-case. That's a real ordering inconsistency, purely cosmetic. I'm happy to flip it to to-first to match the surrounding arms — it's behavior-identical — if you'd like that for consistency. Just say the word and I'll push it; otherwise I'll leave it as-is.

[irodushka]

The worst thing that annoys me is the copypaste in convGuidToString/convGuidToWireString. These foos are 95% identical, except:

1. ODBCCONVERT_CHECKNULL... macro. IMHO it's not significant but it makes sense to deal with the macro zoo;
2. Direct printing to to->dataPtr buffer vs printing via stage tmp buffer & reallocating to->localBuffer;
3. Mention that the line if ( len == -1 ) len = outlen; in the legacy convGuidToString() foo is buggy. -1 means formatting error here == undefined data in the output buffer. len != GUID_STRING_LEN - always means some error.

Can you please explain me this:

// Wire-side counterpart of convGuidToString — writes SQLGUID as the 36-char
// canonical UUID into a Firebird text parameter slot (VARCHAR/CHAR of any
// non-OCTETS charset).  Where convGuidToString writes into an app-supplied
// buffer that the application sized (the SQLGetData fetch path, currently
// dormant until column-side SQL_GUID mapping lands in T5-5 / #287), this
// writes into the *wire* slot — and for an untyped `?` placeholder Firebird
// describes that slot as VARCHAR(0), whose default-sized backing buffer is
// just 1 byte, nowhere near the 36 we need.

?
It's not clear for me... As far I understand that's the case when we bind client-side SQLGUID from var (native 16-bytes GUID) to VARCHAR()/CHAR() to sqlda field, right?

And the corresponding test is:

    SQLRETURN ret = SQLBindParameter(hStmt, 1, SQL_PARAM_INPUT,
        SQL_C_GUID, SQL_GUID, 16, 0, &guid, sizeof(guid), &guidInd);

    // Round-trip through CHAR_TO_UUID then UUID_TO_CHAR — exercises the
    // SQL_C_GUID → VARCHAR wire path on the way in.
    ret = SQLExecDirect(hStmt,
        (SQLCHAR*)"SELECT UUID_TO_CHAR(CHAR_TO_UUID(?)) FROM rdb$database",
        SQL_NTS);

?

I really wonder if this piece is correct.
The parameter is expected to be of CHAR/VARCHAR (TEXT) type and to have a size == 36. So why do you specify the dest type as SQL_GUID and the column size == 16?

Will it work if you write it like
SQLRETURN ret = SQLBindParameter(hStmt, 1, SQL_PARAM_INPUT, SQL_C_GUID, SQL_CHAR, 36, 0, &guid, sizeof(guid), &guidInd); ?

Well, I can understand when you pass GUID in a text form (as CHAR(36)) to the parameter of SQL_GUID type. It's okay. But pass the 16-byte GUID directly to CHAR(36) column... Hmmm...

So as for me - you're trying to make a workaround to serve an incorrect parameter binding.
Look at this (the AI opinion:))) -
https://share.google/aimode/LHNJfo1dG0t7wgRcS

[fdcastel]

Great catches! And one I want to (gently, with receipts 😄) push back on. Took them in order:

1. The len == -1 bug in convGuidToString: right on point.

• snprintf returning −1 is an encoding error, and len = outlen then hands back the whole buffer as if it were valid data. Worse than useless.
• And your stronger framing is the correct invariant: a canonical GUID is always exactly 36 chars, so len != 36 is by definition an error, never something to clamp and carry on. Fixed in c8ae779 — non-36 is now a hard error (HY000), and a too-small destination raises 01004 with the full length reported, matching the ODBC "C to SQL: GUID" contract.

2. The copy-paste: also right, dealt with.

• The genuinely duplicated part was the 11-arg format string living in two places.
• Extracted a single formatGuidCanonical() helper that both functions now call; they keep only their distinct destination handling (app buffer vs staged localDataPtr + setSqlData). Same c8ae779.

3. The macro zoo (ODBCCONVERT_CHECKNULL vs …_SQLDA): agreed it's cosmetic; I'd just rather not fold it into this PR so the GUID change stays focused, but happy to do a small follow-up PR that tames the whole family at once after this one is solved.

4. "Workaround to serve an incorrect parameter binding": this is the one where I think the binding is actually correct, and I went and gathered more evidence. Follow on:

4.a) First, your own question "will it work if you write SQLBindParameter(..., SQL_C_GUID, SQL_CHAR, 36, ...)?": I tested it. On FB 5.0.3, round-tripping through SELECT UUID_TO_CHAR(CHAR_TO_UUID(?)):

C_GUID / SQL_GUID    / 16   ->  A0EEBC99-…-6BB9BD380A11   OK   (current — and what duckdb emits)
C_GUID / SQL_CHAR    / 36   ->  A0EEBC99-…-6BB9BD380A11   OK   (your suggestion)
C_GUID / SQL_VARCHAR / 36   ->  A0EEBC99-…-6BB9BD380A11   OK
C_GUID / SQL_GUID    / 0    ->  A0EEBC99-…-6BB9BD380A11   OK

So your binding works, but... all four land in the same convGuidToWireString 😅

• For a prepared statement the driver converts to the parameter type Firebird described at prepare time (the ? inside CHAR_TO_UUID(?) is text), not to the ParameterType/ColumnSize the app passed.
• So SQL_GUID, 16 vs SQL_CHAR, 36 don't pick different code — the conversion is inherent to getting 16 bytes of GUID into a text parameter.

4.b) Second, the spec actually defines exactly this. The ODBC "C to SQL: GUID" conversion table (learn.microsoft.com) lists SQL_C_GUID → SQL_CHAR (byte length ≥ 36, no error), SQL_VARCHAR (< 36 → 22001), SQL_WCHAR/SQL_WVARCHAR, etc. So stringifying a bound GUID to its 36-char canonical form for a char/varchar parameter is the mandated behavior, not a hack. That same page even answers your "why SQL_GUID, 16?": "The driver ignores the length/indicator value when converting data from the GUID C data type and assumes that the size of the data buffer is the size of the GUID C data type." — i.e. ColumnSize is advisory for SQL_C_GUID, which is why the 16 (and the 0, and the 36) all behaved identically above.

4.c) Third, the real-world reason this exists: duckdb/odbc-scanner binds exactly (SQL_C_GUID, SQL_GUID, 16) (uuid_type.cpp). Before this fix the driver said SQL_SUCCESS and silently wrote garbage. So this isn't us inventing a use case — it's the binding real software emits, and the spec backs it.

Net: I kept the conversion (the spec sanctions it, your own proposed binding exercises the same path), and folded in the bug fix + dedup you spotted. Totally open to being wrong if you read that conversion table differently 😉. But I think on this one the berries turned out to be cherries. 🍒

[fdcastel]

Sorry for the delay in finishing what you asked for; other professional tasks took my available time.

Pushed b303c08. What changed:

• convGuidToWireString is gone. convGuidToString is one function again; it branches on to->isIndicatorSqlDa only for the destination (Firebird side: staged in localDataPtr + setSqlData; application side: copy into the bound buffer with 01004), the same way the original function already branched for the length report.
• The SQL_C_GUID arm switches on to->conciseType first, like its neighbours. CHAR/WCHAR targets take the text or raw-bytes path; everything else falls to notYetImplemented, which restores the 07006 that master returned for a GUID bound to an INTEGER or DATE parameter.
• Any OCTETS slot receives the 16 raw bytes: 16 bytes or more stores the value, fewer is a 22001 from the driver. getSqlLen() is no longer needed and is removed.
• Both Firebird-side writers use ODBCCONVERT_CHECKNULL_SQLDA, so a value bound after a NULL clears the null flag. New tests: that case, 07006, the undersized and the oversized OCTETS slot.

The "VARCHAR(0) / 1-byte buffer" explanation I gave earlier was wrong, and the comments now say what actually happens:

• Reproducer B: with CHARSET=UTF8 Firebird describes the ? in CHAR_TO_UUID(?) as CHAR(36) UTF8, 144 bytes. The driver maps UTF8 text to JDBC_WCHAR, so the old dispatch picked convGuidToStringW and wrote UTF-16 onto the wire; that is the "hex digit at position 2" error. With CHARSET=NONE the slot is CHAR(36) ASCII and the old code passed on Windows by accident, because snprintf is _snprintf there and 36 chars fit exactly with no terminator.
• Reproducer A: the old code stringified into the 16-byte OCTETS slot; _snprintf truncated and returned -1, and the len == -1 line turned that into 16 bytes. So that line was MSVC truncation handling, not an encoding error as my last commit message said.
• The staging buffer is needed because the described slot can be VARYING, shorter than 36 bytes, or a wide-mapped text.

Verified locally on FB 5.0.3 with CHARSET=UTF8 and CHARSET=NONE: all 8 GuidParamBindingTest cases pass, full suite 229 passed, 0 failed under both charsets.