[fpc-devel] Gaps in a non-contiguous enum

Juha Manninen juha.manninen62 at gmail.com
Tue Aug 16 08:43:29 CEST 2022


On Thu, Aug 11, 2022 at 9:37 PM Martin Frb via fpc-devel <
fpc-devel at lists.freepascal.org> wrote:

> fpc code is still "unexpected".
> It takes into account the MinValue
>
> type TMyEnum = (a=5, b=7);
>
> GetEnumName(pt, 5) // a
> GetEnumName(pt, 6) // b // should be 7
>
> if it is just the nth name, then it should start at 0 (or if needs be at
> 1).
>

And function GetEnumValue() is buggy.
This was noticed when testing the original Lazarus enum property editor bug.
A little modified enum :

type
  TFruitMore = (fmApple=1, fmOrange=3, fmBanana=5, fmGrapes, fmPear);
var
  I: Integer;
  EnumType: PTypeInfo;
...
  I := GetEnumValue(EnumType, 'fmBanana');  // Returns 3
  I := GetEnumValue(EnumType, 'fmGrapes');  // Returns 4 which is an
illegal value

Looking at the source of GetEnumValue() the reason is clear.
It increments Count one by one while it should take the gaps into account.
---
     PS:=@PT^.NameList;
     While (Result=-1) and (PByte(PS)^<>0) do
       begin
         If ShortCompareText(PS^, sName) = 0 then
           Result:=Count+PT^.MinValue;
         PS:=PShortString(pointer(PS)+PByte(PS)^+1);
         Inc(Count);
       end;
---
Where are the ordinal values for enums stored? They are not in TTypeData.
I wanted to fix this right away but I have no idea how.

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20220816/2880b286/attachment.htm>


More information about the fpc-devel mailing list