StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>First of all, this has nothing to do with generics, but is a lot more likely to manifest when generics are being used. It turns out there's a buffer overflow bug in <code>TControl.CreateParams</code>. If you look at the code, you'll notice it fills a <code>TCreateParams</code> structure, and especially important, it fills the <code>TCreateParams.WinClassName</code> with the name of the current class (the <code>ClassName</code>). Unfortunately <code>WinClassName</code> is a fixed length buffer of only <code>64</code> char's, but that needs to include the NULL-terminator; so effectively a <code>64</code> char long <code>ClassName</code> will overflow that buffer!</p> <p>It can be tested with this code:</p> <pre><code>TLongWinControlClassName4567890123456789012345678901234567891234 = class(TWinControl) end; procedure TForm3.Button1Click(Sender: TObject); begin with TLongWinControlClassName4567890123456789012345678901234567891234.Create(Self) do begin Parent := Self; end; end; </code></pre> <p>That class name is <em>exactly</em> 64 characters long. Make it one character shorter and the error goes away!</p> <p>This is <em>a lot</em> more likely to happen when using generics because of the way Delphi constructs the <code>ClassName</code>: it includes the unit name where the parameter type is declared, plus a dot, then the name of the parameter type. For example, the <code>TWinControl<TWinControl, TWinControl, TWinControl></code> class has the following ClassName:</p> <pre><code>TWinControl<Controls.TWinControl,Controls.TWinControl,Controls.TWinControl> </code></pre> <p>That's <code>75</code> characters long, over the <code>63</code> limit.</p> <h1>Workaround</h1> <p>I adopted a simple error message from the potentially-error-generating class. Something like this, from the constructor:</p> <pre><code>constructor TWinControl<T, K, W>.Create(aOwner: TComponent); begin {$IFOPT D+} if Length(ClassName) > 63 then raise Exception.Create('The resulting ClassName is too long: ' + ClassName); {$ENDIF} inherited; end; </code></pre> <p>At least this shows a decent error message that one can immediately act upon.</p> <h1>Later Edit, True Workaround</h1> <p>The previous solution (raising an error) works fine for a non-generic class that has a realy-realy long name; One would very likely be able to shorten it, make it 63 chars or less. That's not the case with generic types: I ran into this problem with a TWinControl descendant that took 2 type parameters, so it was of the form:</p> <pre><code>TMyControlName<Type1, Type2> </code></pre> <p>The gnerate ClassName for a concrete type based on this generic type takes the form:</p> <pre><code>TMyControlName<UnitName1.Type1,UnitName2.Type2> </code></pre> <p>so it includes 5 identifiers (2x unit identifier + 3x type identifier) + 5 symbols (<code><.,.></code>); The average length of those 5 identifiers need to be less then 12 chars each, or else the total length is over 63: 5x12+5 = 65. Using only 11-12 characters per identifier is very little and goes against best practices (ie: use long descriptive names because keystrokes are free!). Again, in my case, I simply couldn't make my identifiers that short.</p> <p>Considering how shortening the <code>ClassName</code> is not always possible, I figured I'd attempt removing the cause of the problem (the buffer overflow). Unfortunately that's very difficult because the error originates from <code>TWinControl.CreateParams</code>, at the bottom of the <code>CreateParams</code> hierarchy. We can't NOT call <code>inherited</code> because <code>CreateParams</code> is used all along the inheritance chain to build the window creation parameters. Not calling it would require duplicating all the code in the base <code>TWinControl.CreateParams</code> PLUS all the code in intermediary classes; It would also not be very portable, since any of that code might change with future versions of the <code>VCL</code> (or future version of 3rd party controls we might be subclassing).</p> <p>The following solution doesn't stop <code>TWinControl.CreateParams</code> from overflowing the buffer, but makes it harmless and then (when the <code>inherited</code> call returns) fixes the problem. I'm using a new record (so I have control over the layout) that includes the original <code>TCreateParams</code> but pads it with lots of space for <code>TWinControl.CreateParams</code> to overflow into. <code>TWinControl.CreateParams</code> overflows all it wants, I then read the complete text and make it so it fits the original bounds of the record also making sure the resulting shortened name is reasonably likely to be unique. I'm including the a HASH of the original ClassName in the WndName to help with the uniqueness issue:</p> <pre><code>type TWrappedCreateParamsRecord = record Orignial: TCreateParams; SpaceForCreateParamsToSafelyOverflow: array[0..2047] of Char; end; procedure TExtraExtraLongWinControlDescendantClassName_0123456789_0123456789_0123456789_0123456789.CreateParams(var Params: TCreateParams); var Wrapp: TWrappedCreateParamsRecord; Hashcode: Integer; HashStr: string; begin // Do I need to take special care? if Length(ClassName) >= Length(Params.WinClassName) then begin // Letting the code go through will cause an Access Violation because of the // Buffer Overflow in TWinControl.CreateParams; Yet we do need to let the // inherited call go through, or else parent classes don't get the chance // to manipulate the Params structure. Since we can't fix the root cause (we // can't stop TWinControl.CreateParams from overflowing), let's make sure the // overflow will be harmless. ZeroMemory(@Wrapp, SizeOf(Wrapp)); Move(Params, Wrapp.Orignial, SizeOf(TCreateParams)); // Call the original CreateParams; It'll still overflow, but it'll probably be hurmless since we just // padded the orginal data structure with a substantial ammount of space. inherited CreateParams(Wrapp.Orignial); // The data needs to move back into the "Params" structure, but before we can do that // we should FIX the overflown buffer. We can't simply trunc it to 64, and we don't want // the overhead of keeping track of all the variants of this class we might encounter. // Note: Think of GENERIC classes, where you write this code once, but there might // be many-many different ClassNames at runtime! // // My idea is to FIX this by keeping as much of the original name as possible, but // including the HASH value of the full name into the window name; If the HASH function // is any good then the resulting name as a very high probability of being Unique. We'll // use the default Hash function used for Delphi's generics. HashCode := TEqualityComparer<string>.Default.GetHashCode(PChar(@Wrapp.Orignial.WinClassName)); HashStr := IntToHex(HashCode, 8); Move(HashStr[1], Wrapp.Orignial.WinClassName[High(Wrapp.Orignial.WinClassName)-8], 8*SizeOf(Char)); Wrapp.Orignial.WinClassName[High(Wrapp.Orignial.WinClassName)] := #0; // Move the TCreateParams record back were we've got it from Move(Wrapp.Orignial, Params, SizeOf(TCreateParams)); end else inherited; end; </code></pre>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload