While porting the Delphi Kylix CLX library to fpc, I had errors related to Tbits class. Simply lifting the Delphi implementation into the code solved the problems.

A quick investigations shows that at least the Size property has a different meaning.
While Delphi reports the actual number of allocated bits (i.e. 1-2-3 etc) FPC reports a fixed value of 31 for 1 to 32 bits allocated, and then 63, and so on:

{bits.inc}
function TBits.getSize : longint;
begin
    result := (FSize shl BITSHIFT) - 1;
end;

It seems to me that, besides not being Delphi compatible, this is also wrong, because the actual available space size is (FSize shl BITSHIFT) not decreased by one.

However FPC implementation makes inconsistent the values returned from OpenBit with those obtained reading Size.

Do I miss some point?

Giuliano

However FPC implementation makes inconsistent the values returned from OpenBit with those obtained reading Size. Do I miss some point?

I can imagine bits being allocated in words to avoid endianess problems. So it could be a deliberate deviation for portabilities sake.

Please submit a patch to me. I'll review and apply it.

Michael.

Marco van de Voort ha scritto:

That the implementation needs to be different to support different platforms I can understand. Delphi implementation uses asm code which make it i386 specific.

What I find harder to swallow is that a size of 31 is reported, when the allocated size is 1 and the available size is 32.

Current implementation makes it impossible to detect if an OpenBit has actually created a grow of the bitlist or not, which is necessary if the bitlist is used to keep track of other objects being allocated.

If nobody else is taking care of the matter, as I have a test case ready, I could try and fix TBits implementation, in oder to keep portability but to provide self-consistency, and submit a patch.

Kind regards,

Giuliano

Michael Van Canneyt ha scritto:

Please submit a patch to me. I'll review and apply it.

O.K. Provided I succeed ;-) , I'll do it.

Giuliano