I'm wondering if somebody with access to Tokyo source code could check something for me before I submit a bug report. I just want to be sure that the defect still exists.

I'm wondering if somebody with access to Tokyo source code could check something for me before I submit a bug report. I just want to be sure that the defect still exists.

In Vcl.Imaging.GIFImg, in my XE7 version there is this function:

function TDIBWriter.GetScanline(Row: integer): pointer;
begin
{$ifdef PIXELFORMAT_SLOW}
NeedDIB;

if (FDIBBits = nil) then
Error(sNoDIB);
with FDIBInfo^.bmiHeader do
begin
if (Row < 0) or (Row >= Height) then
raise EInvalidGraphicOperation.Create(SScanLine);
GDIFlush;

if biHeight > 0 then // bottom-up DIB
Row := biHeight - Row - 1;
Result := PByte(Cardinal(FDIBBits) + Cardinal(Row) * AlignBit(biWidth, biBitCount, 32));
end;
{$else}
Result := FBitmap.ScanLine[Row];
{$endif}
end;

The sub-expression Cardinal(FDIBBits) is a pointer truncation bug under the 64 bit compiler. That sub-expression should be NativeUInt(FDIBBits).

I wonder if Emba have done any top down memory allocation testing.

Anyway, would it be possible for somebody with access to the latest Tokyo source code to check whether or not the defect is still present.

Thanks!