There is an inconsistency in behavior between `string.Format(IFormatProvider?, string, *)` and `string.Format(IFormatProvider?, CompositeFormat, *)`.

[kzrnm]

Description

StringBuilder and ValueStringBuilder impose limits on Index and Width, but CompositeFormat.Parse does not, resulting in inconsistent behavior. Since CompositeFormat.Parse also triggers a CA2241 warning, this creates a discrepancy with the analyzer as well.

runtime/src/libraries/System.Private.CoreLib/src/System/Text/StringBuilder.cs

Lines 1523 to 1525 in 54a230f

	// Undocumented exclusive limits on the range for Argument Hole Index and Argument Hole Alignment.
	const int IndexLimit = 1_000_000; // Note: 0 <= ArgIndex < IndexLimit
	const int WidthLimit = 1_000_000; // Note: -WidthLimit < ArgAlign < WidthLimit

runtime/src/libraries/System.Private.CoreLib/src/System/Text/ValueStringBuilder.AppendFormat.cs

Lines 18 to 20 in 54a230f

	// Undocumented exclusive limits on the range for Argument Hole Index and Argument Hole Alignment.
	const int IndexLimit = 1_000_000; // Note: 0 <= ArgIndex < IndexLimit
	const int WidthLimit = 1_000_000; // Note: -WidthLimit < ArgAlign < WidthLimit

runtime/src/libraries/System.Private.CoreLib/src/System/Text/CompositeFormat.cs

Line 112 in 54a230f

private static bool TryParseLiterals(ReadOnlySpan<char> format, List<(string? Literal, int ArgIndex, int Alignment, string? Format)> segments, ref int failureOffset, ref ExceptionResource failureReason)

Reproduction Steps

var numbers = Enumerable.Range(0, 100000000).Cast<object>().ToArray();

Run("Index= 9999999:CompositeFormat", () => string.Format(null, CompositeFormat.Parse("{9999999}"), numbers).Length);
Run("Index=10000000:CompositeFormat", () => string.Format(null, CompositeFormat.Parse("{10000000}"), numbers).Length);
Run("Index= 9999999:string         ", () => string.Format(null, "{9999999}", numbers).Length);
Run("Index=10000000:string         ", () => string.Format(null, "{10000000}", numbers).Length);

Console.WriteLine();

Run("Width= 9999999:CompositeFormat", () => string.Format(null, CompositeFormat.Parse("{0,9999999}"), "format").Length);
Run("Width=10000000:CompositeFormat", () => string.Format(null, CompositeFormat.Parse("{0,10000000}"), "format").Length);
Run("Width= 9999999:string         ", () => string.Format(null, "{0,9999999}", "format").Length);
Run("Width=10000000:string         ", () => string.Format(null, "{0,10000000}", "format").Length);

void Run(string name, Func<object> func)
{
    try
    {
        Console.WriteLine($"{name}: {func()}");
    }
    catch (Exception e)
    {
        Console.WriteLine($"{name}: {e.GetType()}: {e.Message}");
    }
}

Expected behavior

Index= 9999999:CompositeFormat: 7
Index=10000000:CompositeFormat: System.FormatException: Input string was not in a correct format. Failure to parse near offset 10. Format item ends prematurely.
Index= 9999999:string         : 7
Index=10000000:string         : System.FormatException: Input string was not in a correct format. Failure to parse near offset 8. Format item ends prematurely.

Width= 9999999:CompositeFormat: 9999999
Width=10000000:CompositeFormat: System.FormatException: Input string was not in a correct format. Failure to parse near offset 10. Format item ends prematurely.
Width= 9999999:string         : 9999999
Width=10000000:string         : System.FormatException: Input string was not in a correct format. Failure to parse near offset 10. Format item ends prematurely.

Actual behavior

Index= 9999999:CompositeFormat: 7
Index=10000000:CompositeFormat: 8
Index= 9999999:string         : 7
Index=10000000:string         : System.FormatException: Input string was not in a correct format. Failure to parse near offset 8. Format item ends prematurely.

Width= 9999999:CompositeFormat: 9999999
Width=10000000:CompositeFormat: 10000000
Width= 9999999:string         : 9999999
Width=10000000:string         : System.FormatException: Input string was not in a correct format. Failure to parse near offset 10. Format item ends prematurely.

Regression?

No response

Known Workarounds

No response

Configuration

.NET 8 or later

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

[jeffhandley]

Labeled as help wanted, inviting an analysis of the current behavior vs. the expected behavior here--is there a justification for the diverging results?

[caraioniurie47]

Summary

• Nothing in the source or the file history justifies the divergence — it looks like a consequence of copying the parser out of string.Format, not a decision. Add System.Text.CompositeFormat #80753, which added CompositeFormat, also split the invalid-format tests: the two over-limit cases this issue turns on stayed on the string.Format theory, and StringBuilderTests keeps its own copies of both, but neither set reaches CompositeFormat — so CompositeFormat.Parse is not tested against the inputs this issue is about.
• The limit in StringBuilder/ValueStringBuilder is an overflow guard, not a validation rule — a loop condition older than CompositeFormat that tests the running total before folding in the next digit, so the ceiling it really enforces is ten times the constant. It accepts indexes up to 9,999,999, though the constant reads const int IndexLimit = 1_000_000 (StringBuilder.cs:1574).
• The same missing guard lets CompositeFormat.Parse overflow int, which I've filed separately as CompositeFormat.Parse overflows int on a large format-item index, giving IndexOutOfRangeException or a silently wrong argument #133792. It bears on the choice below, so in short: "{2147483648}" parses, stores ArgIndex = int.MinValue and throws IndexOutOfRangeException, which none of the fifteen overloads taking a CompositeFormat document, from all three formatting entry points on main; "{4294967296}" wraps to index 0 and silently formats the wrong argument.
• There are three ways out, and only one fixes both problems at once — giving CompositeFormat the guard the copy dropped.

Read against main at d84e42c; what was run, and on what, is in the note at the bottom.

Three ways out

A — Give CompositeFormat.Parse the guard the original has. Closes the divergence and removes the overflow in one change. Built and run: Parse("{2147483648}") and Parse("{4294967296}") both throw FormatException, so no wrapped index ever reaches a segment and all three entry points fail at Parse instead; "{9999999}" still parses, and all three parsers then agree on the boundary. Nothing CompositeFormatTests feeds it changes: the only over-limit inputs that reach Parse from there are "{1000000" and "{0,1000000", both unterminated, and both still throw for the missing brace. The cost is a behaviour change — an index or alignment above 9,999,999 parses today and would start throwing, "{2147483648}" included. It is the value that is capped, not the digit count: "{00000005}" and "{0,00000005}" are eight digits and still parse, because leading zeros never advance the accumulator. Separately, where Parse sits in a static field initializer the caller doesn't see the FormatException directly — on 10.0.12, with "{1000000", the result is TypeInitializationException at first use of the type, with the FormatException only under InnerException, and the type stays poisoned thereafter. Worth a release note.

B — Bound only the overflow, leaving the ceiling alone. Fail, or stop accumulating, once the index or alignment would exceed int.MaxValue. That removes the overflow without moving the 9,999,999 ceiling, so the inconsistency as reported stands. This is the one option I did not build — it is a description of a change, not a measurement of one.

C — Remove the guard from StringBuilder/ValueStringBuilder so they match CompositeFormat. Closes the divergence from the other side, but spreads the overflow to both of those parsers rather than removing it anywhere. Built and run: string.Format("{4294967296}", "x") returns "x" where it throws today, and StringBuilder.AppendFormat does the same. Two test cases fail, out of the fifty-seven those two tests run — StringBuilderTests.AppendFormat_Invalid, which stops at :964 on an ArgumentOutOfRangeException rather than the asserted FormatException, and the "{0,10000000}" row of StringTests.Format_Invalid_FormatExceptionFromFormatOrArgs, where nothing is thrown at all. Both are alignment rather than index: the "{10000000}" row of that theory still passes, and the index assertions at StringBuilderTests.cs:952-953 run and still throw FormatException before the alignment one aborts the test around them. C does not, however, spread the IndexOutOfRangeException itself: on that build string.Format("{2147483648}", "x") still throws FormatException, because (uint)index >= (uint)args.Length catches the wrapped negative index before it reaches args, so the IndexOutOfRangeException stays a CompositeFormat-only defect.

The ask

Which of the three should I take? The judgement I've deliberately not made is where the ceiling should land — A moves CompositeFormat's effective ceiling down to 9,999,999, and that call belongs to an area owner. I can send a PR for whichever direction is chosen, and won't open one before that. Evidence follows.

Where the limit lives

The same hand-written parser exists in three places in CoreLib, and only two carry the guard:

parser	reached from	guard
ValueStringBuilder.AppendFormatHelper	string.Format, via String.Manipulation.cs:560	IndexLimit/WidthLimit = 1,000,000
StringBuilder.AppendFormat	itself	the same two constants
CompositeFormat.TryParseLiterals	CompositeFormat.Parse	none

CompositeFormat.cs:114 says the parsing logic is "copied from string.Format" and is "the same code modified to not format as part of parsing". The guard is what the copy dropped.

The limit is an overflow guard, not a validation rule

Two things point that way:

1. It is a loop condition, not a check: while (char.IsAsciiDigit(ch) && index < IndexLimit). Exceeding it produces no "value too large" error — digit consumption just stops, the next character then isn't }, , or :, and the generic Format_UnclosedFormatItem fires. Hence "{10000000}" reporting "Input string was not in a correct format. Failure to parse near offset 8. Format item ends prematurely."
2. It stops one digit late, so the ceiling ends up ten times the constant. The test looks at the total accumulated so far, so 999,999 passes it and then absorbs one more digit: the largest reachable value is 999,999 × 10 + 9 = 9,999,999. "{9999999}" therefore parses. "{10000000}" consumes seven of its eight digits, hits exactly 1,000,000, fails the test, and leaves the eighth unconsumed at offset 8 — where the parser wants }, , or : and finds 0. So an over-ceiling index fails for a parse reason rather than a range one, and "{9999999}" being accepted at all contradicts the constant's own comment, // Note: 0 <= ArgIndex < IndexLimit.

It also long predates CompositeFormat: the limit is already in place at this repo's initial CoreCLR import (2024b63acd4, 2015-01-30), written inline as } while (ch >= '0' && ch <= '9' && index < 1000000);. What has happened to it since is only reshaping and copying: dotnet/coreclr#1261 (f00a40c0417, 2016-08-04) lifts that literal into a named constant, dotnet/coreclr#10156 (9b6c57b0e23, 2017-06-18) renames that constant to IndexLimit, ebb868605b2 (2019-10-25) copies the whole parser into ValueStringBuilder, carrying the limit with it, and #69757 (06a8b48e44c, 2022-06-06) respells it 1_000_000 while rewriting the loop. So no commit in this repo chose the number or says why it is what it is — fitting the "Undocumented exclusive limits" comment above it.

The divergence dates from CompositeFormat's introduction

The invalid-format tests record it. Before #80753 (8798c0459a3, 2023-01-20) one Format_Invalid test asserted that "{1000000", "{10000000}", "{0,1000000" and "{0,10000000}" all throw from string.Format. That PR split it: the two unterminated cases went into the shared MemberData that CompositeFormatTests consumes (CompositeFormatTests.cs:199), while the two closed over-limit cases stayed as [InlineData] on the string.Format-only theory. StringBuilderTests keeps its own coverage of both closed forms. I can't read intent off a diff and won't guess at it — but as a matter of record, the divergence is as old as the type, and neither the source nor the history offers a rationale.

The four sites that cover the closed over-limit cases today are System.Runtime.Tests/System/Text/StringBuilderTests.cs:952-953 and :964-965, and the two [InlineData] rows at Common/tests/Tests/System/StringTests.cs:2856-2857. Those are the ones option C above was measured against.

Note

AI-generated, written at my direction and reviewed by me before posting. The behaviour reported here was executed, not inferred: on .NET 10.0.12, on a local main build at d84e42c (clr+libs -rc release, reporting 12.0.0-dev), and for options A and C on two further builds of that tree with the guard added to CompositeFormat and removed from StringBuilder/ValueStringBuilder. Option B was not built. The static-initializer check ran on 10.0.12 only, with a format string that fails on the shipped runtime too. The source, test and git-history claims were checked against the repo at d84e42c.