Hi,

As described in
http://bugs.freepascal.org/view.php?id=22797

fpc 2.7.1 does not allow anymore to pass an enum
to a function expecting integers.

Note that there has always been a
{$MINENUMSIZE 4} in qt4.pas

Is this intended behaviour ? I really hope it is not.

I cannot define the type of the parameter
as the enumtype because the expected values
are either the enum or combinations of the enum (or)

Kind regards,

Den Jean

2012/9/10 Den Jean :

If it is the combination of enum, then the type of the parameter is set of enum.

Vincent

Vincent Snijders wrote

If it is the combination of enum, then the type of the parameter is set of enum.

Ahum, I am talking about passing combinations of enums values (usually bitmasks, assigned enums, some assigned enums are already combinations of other) to C or C++.
Sets are not binary compatible for that.

Op Mon, 10 Sep 2012, schreef Den Jean:

They should be.

Daniël

In our previous episode, Dani?l Mantione said:

Afaik {$mode delphi} doesn't auto enable the equivalent packenum/set. I noticed that last week too.

No, sets are an opaque data type. Their internal format is undefined.

Jonas

This has never been allowed. The only thing that was allowed was defining an enum as a default value for integer parameters. But then again, you could also define a char, a floating point value, a string, or really anything as default value for any kind of parameter. The compiler was simply missing any kind of type checking for the default value.

Note that there has always been a {$MINENUMSIZE 4} in qt4.pas

That defines the size, not the type.

Is this intended behaviour ? I really hope it is not.

It is.

I cannot define the type of the parameter as the enumtype because the expected values are either the enum or combinations of the enum (or)

As mentioned above, that never worked in the past either.

Jonas

Op Mon, 10 Sep 2012, schreef Jonas Maebe:

I knew you would answer to that :) While, I disagree that a set is opaque, but, we can skip that discussion. What's going on here is that, wether it is a good idea or not, the implementor of the QT interface units is trying to provide Pascal data types to its user. Given the fact you are doing that, a set of enum is IMO as reasonable as other weak type to strong type mappings.

Daniël

If you want to do that, you need to add a layer in between that converts the sets into integer bitmasks in a reliable, portable and future-proof way.

Jonas

Op Mon, 10 Sep 2012, schreef Jonas Maebe:

If you want to do that, you need to add a layer in between that converts the sets into integer bitmasks in a reliable, portable and future-proof way.

Yes! Let's also convert integers to enums with a case statement rather than typecast, just in case the compiler may not count enums from zero in the future ;)

Daniël

You can explicitly define the ordinal values of enumerations if you depend on that sort of stuff (which afaik the Qt units in fact do).

Jonas

Op Mon, 10 Sep 2012, schreef Jonas Maebe:

That's a rewriting of history, as we invented that feature. Obviously people were writing interfaces to external libraries before that. Were those programmers wrong? Not at all, they could succesfully rely on guaranteed binary representations in Borland manuals.

Daniël

With as primary reason: interfacing with external C libraries.

Obviously people were writing interfaces to external libraries before that. Were those programmers wrong? Not at all, they could succesfully rely on guaranteed binary representations in Borland manuals.

If the Borland defined that enumerations always start at 0, we will guarantee that too.

Jonas

Jonas Maebe wrote

If you want to do that, you need to add a layer in between that converts the sets into integer bitmasks in a reliable, portable and future-proof way.

How about packed sets? Do they have well-defined memory layout? If not, then maybe they should?

Op Tue, 11 Sep 2012, schreef Alexander Klenin:

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. This is how it is documented in FPC documentation. Packed is ignored on sets and I don't see a need for a packed set with a different binary representation, but *should* sets every become unreliable in binary representation, I would agree with you that there is a need for a packed set that is reliable.

Daniël

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

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.