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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
