[solved] strange behavior with constant set

[Joanna from IRC]

I'm trying to load a set of integer values into a combobox
It seems like it doesn't work correctly when set is passed as a parameter

if I try to send the set to load into combobox as a parameter it ignores the 102..105 part of set.
If i send a set [0..105] it stops loading when it gets to 31 items.
if I send [102..105] as a parameter it says its an empty set and loads nothing

If i use a locally declared set it works perfectly

Code: Pascal  [Select][+][-]

1. PROCEDURE TINI_COMBOBOX.ASSIGN( CONST ASET: TINTEGERSET) ;
2.            const VALS = [0..7,102..105]; // this works ok if i use this one
3.            VAR X:INTEGER;
4.  BEGIN
5. Clear;
6.  //FOR X IN VALS DO  // this works perfectly
7.  //   AddItem(X.ToString,NIL);
8. FOR X IN ASET DO // this can't load the higher numbers
9.     AddItem(X.ToString,NIL);
10. END;    
11.  

anyone know what would cause such strange behavior?

using win 7
Lazarus 2.0.12 r64642 FPC 3.2.0 x86_64-win64-win32/win64

[ASerge]

anyone know what would cause such strange behavior?

Not strange, because TIntegerSet = [0..31].

[MarkMLl]

What appears to be happening is that the set type is defaulting to one with 32 elements, i.e. the same as an integer.

I'm not sure what the limitation on the number of elements in a set is these days but it won't be large. However what you want to do is set up a type with that number of elements, and then use that type explicitly when setting up a constant, passing a parameter and so on.

You might need to distill this down to a compilable test program: SOP, sorry but I shouldn't have to mention it.

MarkMLl

[Joanna from IRC]

I always thought that sets had 255 elements possible with ordinal or positive integers . I never heard of 32 element set before.

I’m not sure how to create a larger set type it won’t let me.

[dseligo]

I always thought that sets had 255 elements possible with ordinal or positive integers . I never heard of 32 element set before.

According to manual, you are right (256, not 255): https://www.freepascal.org/docs-html/3.2.0/ref/refsu16.html

[Joanna from IRC]

I was thinking 0 to 255 
Is there any way to prevent the set from being messed up when it’s sent as a parameter ?

[cdbc]

Hi

Is there any way to prevent the set from being messed up when it’s sent as a parameter ?

Yes, define your own set type that holds more than 0..31... e.g.:

Code: Pascal  [Select][+][-]

1. type
2.   TJIntSet = set of 0..255;

Regards Benny

[Joanna from IRC]

Code: Pascal  [Select][+][-]

1. PROCEDURE TNUM_COL_FILTER.TEST;
2.            TYPE BIGSET = SET OF 0..255;
3.            CONST
4.            VALS:BIGSET = [0..7,102..105];
5.  BEGIN
6.   COMBOBOX.Assign(VALS);
7. END;

i tried this and it compiles just fine but ignores the 102..105 part

[MarkMLl]

According to manual, you are right (256, not 255): https://www.freepascal.org/docs-html/3.2.0/ref/refsu16.html

Noting that that's the maximum size, not the default.

How many bytes the compiler uses to store a sets depends on the mode. For non-Delphi modes, the compiler stores small sets (less than 32 elements) in a Longint, if the set element type range allows it. This allows for faster processing and decreases program size. Otherwise, sets are stored in 32 bytes.

And I expect that OP's got range checking etc. turned off.

MarkMLl

[cdbc]

Hi
I meant use the new type here:

Code: Pascal  [Select][+][-]

1. PROCEDURE TINI_COMBOBOX.ASSIGN( CONST ASET: TJIntSet) ; //<---HERE

Regards Benny

[jamie]

For a test, and this would confirm if there were an issue building a SET parameter for the function of that or I am just blowing smoke!

have you tried using a CONSTREF instead of CONST?

[Joanna from IRC]

For a test, and this would confirm if there were an issue building a SET parameter for the function of that or I am just blowing smoke!

have you tried using a CONSTREF instead of CONST?

I’m not sure what a consfref is?

And I expect that OP's got range checking etc. turned off.
MarkMLl

that’s a bizarre accusation. Why would I not want range checking?
I’m using fpc mode but I never knew about the default set being truncated.

Cdbc I tried what you told me and it works. I’m still flabbergasted That it would truncate a set rather than adjust to the size needed.

Thanks everyone for the insights

[MarkMLl]

And I expect that OP's got range checking etc. turned off.
MarkMLl

that’s a bizarre accusation. Why would I not want range checking?

I’m still flabbergasted That it would truncate a set rather than adjust to the size needed.

If your range checking is on but a set is being truncated without warning at either compilation or runtime, my own feeling is that that should be considered an error. But you'd not posted a compilable example or told us exactly how you were building... /fortunately/ we can't all read your mind.

Somebody's mentioned that sets can contain 256 elements, but that is the /maximum/ number they can contain, and the manual is explicit that by default they're a longint... you did read that bit I quoted, didn't you?

So what's happening is that because you hadn't specified a set type it was defaulting to 32 elements, but then- apparently- silently discarding bits from an allocation. That's /wrong/, but at the same time your use of an implicit set type in that parameter list was arguably a bit dodgy... only a bit though, and I can sympathise.

There's a related problem where the shifting operator silently ignores an operand of larger than (I think) 31.

MarkMLl

[Bart]

It seems that at least Delphi 7 behaves similar.

Code: Pascal  [Select][+][-]

1. program test;
2. {$ifdef fpc}
3. {$mode objfpc}
4. {$h+}
5. //{$mode delphi}
6. {$endif}
7. {$apptype console}
8.  
9. uses
10.   sysutils;
11.  
12. Var
13.   Z: TIntegerSet;
14.   L: LongInt absolute Z;  //using typecast here since D7 cannot do for..in loop
15. begin
16.   {$R+}
17.   if SizeOf(TIntegerSet) <> SizeOf(LongInt) then RunError(1);
18.   Z := [0,28];
19.   writeln(IntToHex(L,4));
20.   Z := [0,28,101,102];
21.   writeln(IntToHex(L,4));
22. end.

Code: [Select]

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc test.pas
Free Pascal Compiler version 3.3.1 [2024/03/12] for i386
...
26 lines compiled, 0.2 sec, 73024 bytes code, 4580 bytes data
1 warning(s) issued

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
10000001
10000001

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>dcc32 test.pas
Borland Delphi Version 15.0
Copyright (c) 1983,2002 Borland Software Corporation
test.pas(27)
28 lines, 0.03 seconds, 29244 bytes code, 2973 bytes data.

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
10000001
10000001

As you can see both sets [0,28] and [0,28,101,102] are the same and no runtime error occurs with RangeChecking on.

Bart

[Joanna from IRC]

Markml that might explain the cutting off adding things at 31 items but it doesn’t explain it ignoring the set of values over 100. They are perfectly valid. So there are really two issues, the truncating at 31 items and the ignoring a set of higher values.