Possible reason why compilation of Sparkle feils

After opening bplsparkle.so in Linux and compiling the debug version, I followed the error messages and found that the fail occure in the call on Sparkle.Middleware.Compress.pas:line 278 where lines call directly deflate(FZstream, zfinish) in the ines:
while ZCompressCheckWithoutBufferError(deflate(FZStream, Z_FINISH)) <> Z_STREAM_END do
begin
FStream.WriteBuffer(FBuffer, Length(FBuffer) - Integer(FZStream.avail_out));

  FZStream.next_out := @FBuffer[0];
  FZStream.avail_out := Length(FBuffer);

And on line 291 there is a direct call to deflateend(FZstream);

When expanding the system.zilib.pas and press F1 on the commands, help for for system.Zlib.deflate tate explicitly the the unction call if for internal use only and

System.ZLib.deflate .appmethod { display:none; }

Properties

Type Visibility Source Unit Parent
function public System.ZLib.pas

System.ZLib.hpp|System.ZLib|System.ZLib|

Description

For internal use only.

Do not use this function. It is for internal use only. For more information, see the original documentation provided by ZLib library.

Category:

Samme applies for the other function call. to zlib where diret call should have been overwritten by some methods calling it correctly.

1 Like

When the gzip internal method of an external library, shouldn't that always flagged as an error, also when comompiling for win32 or any of the other platforms ??

Maybe there is a need for a new error message?

Illegal call to an internal method inside an external library ?

Added a report in quality portal, [RSP-38111] Shouldn't illegal method call in external library also generate at least a watning or generate an error status if called frokm outside the library? - Embarcadero Technologies

Hope there is some interest to have this applied

1 Like

I don't think that's a problem. The documentation says it's for internal only simply because it's a more low level function. It's pretty much valid ZLib method that is called by the ZLib unit itself.

It works on Windows and also worked on Linux until a recent minor Delphi update which got broken. It even works on Debug config but not on Release config. It's plain and simple a Delphi bug that should be fixed.

For my part, the release version compiles fine, but the debug version fails in the flush method:

procedure TXDataCompressionStream.Flush;
begin
FZStream.next_in := nil;
FZStream.avail_in := 0;

try
if FStream.Position <> FStreamPos then FStream.Position := FStreamPos;

while ZCompressCheckWithoutBufferError(deflate(FZStream, Z_FINISH)) <> Z_STREAM_END do
begin
  FStream.WriteBuffer(FBuffer, Length(FBuffer) - Integer(FZStream.avail_out));

  FZStream.next_out := @FBuffer[0];
  FZStream.avail_out := Length(FBuffer);
end;

if Integer(FZStream.avail_out) < Length(FBuffer) then
begin
  FStream.WriteBuffer(FBuffer, Length(FBuffer) - Integer(FZStream.avail_out));
end;

finally
deflateEnd(FZStream);
end;
end;

Maybe both bug reports would have been solved if Calvin Tang or other involved from Embarcadero had been provided with complete description of where bug occures, like let them install the needed components of the Biz packge so they could test the above function of why it fails.

If adding system.zlib to the two function names, all compiles ok

procedure TXDataCompressionStream.Flush;
begin
FZStream.next_in := nil;
FZStream.avail_in := 0;

try
if FStream.Position <> FStreamPos then FStream.Position := FStreamPos;

while ZCompressCheckWithoutBufferError(system.ZLib.deflate(FZStream, Z_FINISH)) <> Z_STREAM_END do
begin
  FStream.WriteBuffer(FBuffer, Length(FBuffer) - Integer(FZStream.avail_out));

  FZStream.next_out := @FBuffer[0];
  FZStream.avail_out := Length(FBuffer);
end;

if Integer(FZStream.avail_out) < Length(FBuffer) then
begin
  FStream.WriteBuffer(FBuffer, Length(FBuffer) - Integer(FZStream.avail_out));
end;

finally
system.ZLib.deflateEnd(FZStream);
end;
end;

1 Like

That's definitely something we can modify in source code. If it works around the compilation problem, it would be great. We will include it in next release.

Solution that worked for me. Under Debug configuration - Linux 64-bit platform, I turned off "Use debug .dcus" and it compiled without problems in debug mode.

1 Like