Re: [fpc-devel] enums and integer auto conversion
In our previous episode, Dani?l Mantione said:
> Sets, are a bit more complicated: Their binary layout is defined in
> Borland documentation, but this one of the few issues were FPC didn't
> follow Borland. FPC has smallsets, up to 32 items and longsets, up to 256
> items.
That's outdated, running
{$packset 4}
type TBit64=0..63;
TBitSet64 = set of TBit64;
begin
writeln(sizeof(tbitset64));
end.
yields "8".
Last week I had to add this packset in addition to $Mode delphi to compile
delphi
code.
A difference with Delphi is that delphi iirc also allows multiple of 1s, and
fpc only allows 1,2,4.. (multiples of 4 bytes)..32.
IIRC that had to do with endianess of sets, keeping them (d)word addressable.
The 4 byte magnitude doesn't scale to 8 byte on 64-bit though.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] enums and integer auto conversion
On 11 Sep 2012, at 06:18, Alexander Klenin wrote: > How about packed sets? Do they have well-defined memory layout? If > not, then maybe they should? Set packing only influences the number of bytes occupied by sets, not their internal layout. And I don't think that should change, because they are orthogonal issues. You'd need a new directive that would enable unambiguously specifying the layout of sets. That would require a lot of code generator changes though. And as an aside, using sets to represent bitmasks isn't even possible today if you want portable code, because the current layout on big endian systems does not correspond to or'ing (1 shl ord(enumval)). You could of course start changing the ordinal values of the enums on big endian systems to compensate, but then you get in trouble if they are sometimes also used in a non-bitmask context. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
