[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