1754803 - nsDataObj::BuildPlatformHTML will misbehave given ~1GB of data

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect, P3)

Description

[Ray Kraesig [:rkraesig]]

The Win32-specific function nsDataObj::BuildPlatformHTML expects that the printed size of its outgoing data will fit in eight characters. It will fail (via OOM) if we try to copy 1e9 bytes' worth of HTML.

At time of writing, this behavior can't actually be triggered; it's concealed by bug 1524237.

Comment 1

[David Parks [:handyman]]

This code goes back to bug 69363. It's not clear why the format specifiers are of fixed (limited) width but the CF_HTML type doesn't seem to require it. We could try increasing them.

Comment 2

[Ray Kraesig [:rkraesig]]

(In reply to David Parks [:handyman] from comment #1)

This code goes back to bug 69363. It's not clear why the format specifiers are of fixed (limited) width

It's because the data whose length is described by the value includes the representation of the value itself. If it's potentially variable-width, calculating what it needs to be gets hairier.

We could try increasing them.

I'm a bit leery of that — but only because it's been like this for 20+ years, and by now there are probably a lot of ill-maintained programs and scripts which expect 8-character fields out of us and will break if they get anything else. We can't help them for 1GB copies, but we could at least avoid breaking them for the usual case.

Comment 3

[Stephen A Pohl [:spohl]]

(In reply to Ray Kraesig [:rkraesig] from comment #2)

I'm a bit leery of that — but only because it's been like this for 20+ years, and by now there are probably a lot of ill-maintained programs and scripts which expect 8-character fields out of us and will break if they get anything else. We can't help them for 1GB copies, but we could at least avoid breaking them for the usual case.

Drive-by comment: "ill-maintained programs and scripts" alone should not be a reason to hold off on improving/enhancing our code. There may be other reasons to hold off here, but this particular one shouldn't be one.

Comment 4

[Ray Kraesig [:rkraesig]]

Attachment: Bug 1754803 - expand size-field to 16 digits if 8 won't suffice r?handyman

... while retaining the existing 8-wide padding for backward
compatibility with existing consumers.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dfdce7cc09a9
expand size-field to 16 digits if 8 won't suffice  r=handyman

Comment 6

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/dfdce7cc09a9