[fpc-devel] TypeInfo GetSetProp and GetEnumName

[Martin Frb]

Looking through some code in unit TypInfo
in relation to https://bugs.freepascal.org/view.php?id=38915

RTTI for a set, only specifies the size in bytes. (TTypeDate.SetSize)
GetSetProp / SetToString
iterate over all bits on the given byte size.
Since in many cases this is more than the actual amount of elements in 
the set, those function relay on the unused bits to be always zero.  
(Which is probably always a given / pointer hacks and uninitialized 
excluded).

GetEnumName when (if the unused bits were to contain a 1) called with a 
value greater than the enums, would gladly iterate behind its NameList.
And in doing so, could leave the applications memory space (though 
unlikely, as the enum rtti would need to be just before the end of mem 
assigned to the app).

GetEnumName  does
- neither check the TTypeData.MaxValue,
- nor does it check for the terminating nil  (see below)

Is that indented?
Or should GetEnumName have some checks?


----------------
on the RTTI for enums

fpc_3.2.2\source\compiler\ncgrtti.pas
procedure enumdef_rtti(def: tenumdef);
line 990;
           { write zero which is required by RTL }
           tcb.emit_ord_const(0,u8inttype);

Out of interest: That call is inside a (several) tcb.begin_anonymous_record
I would therefore expect (target depended) that "u8inttype" may be aligned?

I have not (yet) found where this zero value is actually used.

But if it might be aligned, I am curious, because it ends a list of 
shortstring.
Therefore any code, after iterating over the last such shortstring would 
likely be at an unaligned location, and not necessary at the zero qword?
On the other hand, it might be padding, never to be used, just to ensure 
the existence of valid/accessible memory?
In the latter case of course this would not prevent any over-read by 
SetToString on a dirty set value.