Delphi 当控件';s的类名很长很长?

Delphi 当控件';s的类名很长很长?,delphi,delphi-2010,buffer-overflow,Delphi,Delphi 2010,Buffer Overflow,我按顺序对一个控件进行了子类化,以便添加一些需要的字段,但现在当我在运行时创建它时,我得到了一个访问冲突。不幸的是,这种访问冲突不会发生在我创建控件的地方,即使是那些我在构建时启用了所有调试选项(包括“使用调试DCU构建”)的地方,堆栈跟踪对我也没有任何帮助 在我试图重现错误的过程中,我尝试创建一个控制台应用程序,但显然,这个错误只出现在窗体应用程序中,并且只有当我的控件实际显示在窗体上时才出现 以下是重现错误的步骤。创建一个新的VCL表单应用程序,拖放一个按钮,双击以创建OnClick处理程序

我按顺序对一个控件进行了子类化,以便添加一些需要的字段,但现在当我在运行时创建它时,我得到了一个
访问冲突
。不幸的是,这种访问冲突不会发生在我创建控件的地方,即使是那些我在构建时启用了所有调试选项(包括“使用调试DCU构建”)的地方,堆栈跟踪对我也没有任何帮助

在我试图重现错误的过程中,我尝试创建一个控制台应用程序,但显然,这个错误只出现在窗体应用程序中,并且只有当我的控件实际显示在窗体上时才出现

以下是重现错误的步骤。创建一个新的VCL表单应用程序,拖放一个按钮,双击以创建OnClick处理程序并编写以下内容:

type TWinControl<T,K,W> = class(TWinControl);

procedure TForm3.Button1Click(Sender: TObject);
begin
  with TWinControl<TWinControl, TWinControl, TWinControl>.Create(Self) do
  begin
    Parent := Self;
  end;
end;
类型TWinControl=class(TWinControl);
程序TForm3.按钮1单击(发件人:ToObject);
开始
使用TWinControl.Create(Self)do
开始
父母:=自我;
结束;
结束;
每次我尝试时,都会连续生成访问冲突。仅在Delphi 2010上测试过,因为这是我在这台计算机上得到的唯一版本

问题是:

  • 这是Delphi泛型中已知的错误吗
  • 有解决办法吗
编辑
这里是QC报告的链接:

首先,这与泛型无关,但在使用泛型时更可能表现出来。原来
TControl.CreateParams
中存在缓冲区溢出错误。如果查看代码,您会注意到它填充了一个
TCreateParams
结构,尤其重要的是,它用当前类的名称填充了
TCreateParams.WinClassName
。不幸的是,
WinClassName
是一个只有
64
char的固定长度缓冲区,但需要包括空终止符;因此,一个
64
char long
ClassName
将有效地溢出该缓冲区

可以使用以下代码对其进行测试:

TLongWinControlClassName4567890123456789012345678901234567891234 = class(TWinControl)
end;

procedure TForm3.Button1Click(Sender: TObject);
begin
  with TLongWinControlClassName4567890123456789012345678901234567891234.Create(Self) do
  begin
    Parent := Self;
  end;
end;
该类名的长度正好是64个字符。缩短一个字符,错误就会消失

这在使用泛型时更可能发生,因为Delphi构造
类名的方式:它包括声明参数类型的单元名,加上一个点,然后是参数类型的名称。例如,
TWinControl
类具有以下类名:

TWinControl<Controls.TWinControl,Controls.TWinControl,Controls.TWinControl>
至少这显示了一个可以立即采取行动的适当错误消息

稍后编辑,真正的解决方法 前面的解决方案(引发错误)适用于名称非常长的非泛型类;人们很可能会缩短它,使它不超过63个字符。泛型类型不是这样的:我遇到了一个TWinControl子体的问题,它有两个类型参数,所以它的形式是:

TMyControlName<Type1, Type2>
TMyControlName<UnitName1.Type1,UnitName2.Type2>

下次你已经知道你要发布的问题的答案时,点击“回答你自己的问题”框,这样你就可以同时发布问题和答案。我指的是“提问”页面上的复选框。您可以同时提问和回答。@NGLN,请随意编辑并使标题更有用。我不知道人们怎么会再次遇到这个问题,但我确实花了一段时间才弄明白,所以我希望它能帮助一些人。我正忙着调试这个问题,正要发布一个答案,这时你的答案出现了。我没有意识到我们在玩游戏。好吧。您可能可以截取
TWinControl.CreateParams
,并从内部修复此问题。你已经提交了质量控制报告了吗?@DavidHeffernan:API允许256个字符,我不知道为什么会有人提出64个字符的限制。
lpszClassName
可能早在早期就被限制在64个字符,但后来增加到256个字符,没有人修复VCL。它是在Delphi.NET和FMX中解决的,但直到今天仍然在VCL中被破坏(至少在10.0西雅图,我还没有检查更高版本)。我已在质量门户中提交了一份新的缺陷报告:
TMyControlName<UnitName1.Type1,UnitName2.Type2>
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;