Fix SQLLEN implicit conversion overflow for -1 values from ODBC drivers with defensive validation

[Copilot]

Description

Fixes #115389 - System.Data.Odbc SQLLEN does not handle -1 correctly

This PR fixes an OverflowException that occurs when querying ODBC databases (such as Filemaker Pro) that return -1 as a field length indicator on 64-bit platforms, while preventing potential data corruption from truly out-of-range values.

Problem

Some ODBC drivers represent field lengths as -1 (unknown/variable length) using the value 0x00000000FFFFFFFF. On 64-bit platforms:

• This value is stored in a 64-bit IntPtr as 4294967295
• The implicit conversion operator in SQLLEN called ToInt32() to convert to int
• ToInt32() throws OverflowException because 4294967295 > Int32.MaxValue (2147483647)

This issue does not affect Java ODBC connectors, which handle this conversion differently.

Solution

Updated the implicit conversion operator in SQLLEN struct to use a defensive approach:

1. Specific Sentinel Value Handling: Explicitly checks for common ODBC sentinel values when they are improperly represented without sign extension on 64-bit platforms:

   • 0x00000000FFFFFFFF → -1 (SQL_NULL_DATA)
   • 0x00000000FFFFFFFD → -3 (SQL_NTS)
   • 0x00000000FFFFFFFC → -4 (SQL_NO_TOTAL)

2. Range Validation: For all other values, uses checked((int)longValue) which throws OverflowException if the value is outside the Int32 range.

This approach:

• Fixes the Filemaker Pro driver issue (and similar drivers with improper sign extension)
• Prevents silent data corruption by validating all non-sentinel values fit in Int32 range
• Maintains the existing behavior of throwing exceptions for truly invalid data
• Only handles specific known problematic patterns

Testing

Added comprehensive unit tests (SQLLENTests.cs) that verify:

• The problematic sentinel values 0x00000000FFFFFFFF, 0x00000000FFFFFFFD, and 0x00000000FFFFFFFC on 64-bit platforms correctly convert to their respective negative values
• Normal positive values continue to work correctly
• Zero and negative values work correctly
• Out-of-range values (e.g., 0x0000000100000000) still throw OverflowException as expected
• All existing tests pass

Validation

Created a demonstration program confirming:

• Old behavior: Throws OverflowException when encountering 0x00000000FFFFFFFF
• New behavior: Successfully converts sentinel values to their intended negative values, while still throwing for truly out-of-range data

This is a surgical fix that resolves the issue while maintaining data integrity and backward compatibility.

Fixes #115389

Original prompt

---

This section details on the original issue you should resolve

<issue_title>System.Data.Odbc - SQLLEN does not handle -1</issue_title>
<issue_description>### Description

Hi .NET Team
When querying Filemaker Pro ODBC databases through .NET ODBC, we're running into some issues.
(This does not affect Java ODBC connectors)

Specifically, it seems that some fields represent their length as 0x00000000ffffffff (-1).

This is causing overflow errors in SQLLEN.cs when trying to parse the field at this code:

	public static implicit operator int(SQLLEN value)
	{
		return ((IntPtr)value._value).ToInt32();
	}

Instead of:

return ((IntPtr)value._value).ToInt32();

I think the code should be:

return (int)value.ToInt64();

Reproduction Steps

I can provide a sample database if contacted

Expected behavior

No Error occurs

Actual behavior

An overflow exception occurs.

Regression?

No response

Known Workarounds

I can wrap the access and return null if this happens.

Configuration

.NET 9.0 on Windows.

Other information

Java ODBC libraries are not affected by this issue.</issue_description>

Comments on the Issue (you are @copilot in this section)

@SamMonoRT We will not get to this anytime soon. Adding to 10.0 milestone for tracking @SamMonoRT This has a known work-around, will not be able to get to the actual fix in 10.0. Moving to 11.0 @SamMonoRT Hey @TonyValenti - I was referring to "Known Workarounds - I can wrap the access and return null if this happens." Given other priorities, yes, this is going to be extremely difficult getting this in for 10.0 - we do welcome community PRs if anyone wants to give it a try. @SamMonoRT Got it, we'll see if we can get something in for 10.0, but looks unlikely.

Fixes #115389

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[dotnet-policy-service]

Tagging subscribers to this area: @roji, @SamMonoRT
See info in area-owners.md if you want to be subscribed.

[stephentoub]

@copilot, while this might address the particular problem, is this going to introduce new issues, where incorrect data is interpreted as being valid?

[Copilot]

Good catch. I've updated the implementation to be more defensive. Instead of blindly truncating, it now:

1. Specifically checks for the three common ODBC sentinel values when improperly represented (0x00000000FFFFFFFF → -1, 0x00000000FFFFFFFD → -3, 0x00000000FFFFFFFC → -4)
2. Uses checked((int)longValue) for all other values, which throws OverflowException if out of Int32 range

This prevents silent data corruption while fixing the Filemaker Pro driver issue. Added tests to verify out-of-range values still throw.

Commit: 4f813d6