benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Upgrade: fix test-failures(2)

Browse source 
seems that I've played too much with »undefined behaviour« in this test;
basically we can not assume ''any'' specific placement of local variables
in a stack frame....

In this test, what I wanted to demonstrate is that the overflow-block can reside
just »anywhere«, and that HeteraoData is just a light-weight front-End and accessor.

However, I can just demonstrate that without totally ''undefined behaviour;''
placement-new can be used to force the storage at a specific location (in the UninitialiesdStorage);
continue to access and use that data after leaving the nested scope is still
kind-of borderline, yet demonstrates that the data itself is just residing in a storage block...
This commit is contained in:
Fischlurch 2025-04-25 19:02:04 +02:00
parent 1d3cb6b23b
commit 4ce936529e
2 changed files with 44 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
tests/library/hetero-data-test.cpp
View file

@ -226,11 +226,11 @@ namespace test{
CHECK (get4(front) == "Ψ");
// further allocations can even be »elsewhere«
const void* loc;
lib::UninitialisedStorage<Data3, 1> evilSpace;
const void* loc = &evilSpace;
{
Acc6 get6;
auto magic = Cons3::build("magic","cloud");
loc = getAdr(magic);
auto& magic = * new(&evilSpace) Cons3::NewFrame{"magic","cloud"};
CHECK (magic.get<0>() == "magic"_expect);
CHECK (magic.get<1>() == "cloud"_expect);
// link into the cloud...
@ -240,13 +240,18 @@ namespace test{
// it's gone
// Evil, evil...
lib::UninitialisedStorage<Data3, 1> evilSpace;
Data3& d3 = evilSpace[0]; // note: working with left-over data from expired stack frame
CHECK (isSameAdr (d3, loc));
CHECK (d3.get<0>() == "magic"_expect); // const char* points into static data, so the chars are still there
new(&d3.get<1>()) string{"mushrooms"}; // the "cloud"-string was destroyed by magic's destructor
new(&d3.get<1>()) string{"mushrooms"}; // ...but we can implant another message here....
auto& [v1,v2,v3,v4,v5,v6] = Cons3::recast(front); // using connectivity from the linked list connecting the segments
// All of this demonstrates that HeteroData is really
// just a light-weight front-end and access structure
// pointing to a data block that can be »anywhere«
// Since for this test we keep the evilSpace allocated,
// it is possible to continue accessing the data block,
// using connectivity from the linked list connecting the segments
auto& [v1,v2,v3,v4,v5,v6] = Cons3::recast(front);
CHECK (v1 == "0"_expect);
CHECK (v2 == "2.3"_expect);
CHECK (v3 == "false"_expect);
@ -293,7 +298,7 @@ namespace test{
// Note: basically we are still using stale memory,
// previously allocated to the "magic" block,
// and now covered by the UninitialisedStorage
// and still covered by the UninitialisedStorage
CHECK (loc == & d3);
CHECK (loc < & v5);
CHECK (loc < & v6);

33
wiki/thinkPad.ichthyo.mm
View file

@ -161877,8 +161877,39 @@ Since then others have made contributions, see the log for the history.</font></
<arrowlink COLOR="#5c3279" DESTINATION="ID_721065474" ENDARROW="Default" ENDINCLINATION="-13;95;" ID="Arrow_ID_1372407656" STARTARROW="None" STARTINCLINATION="13;-103;"/>
</node>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1745537946821" ID="ID_1319727141" MODIFIED="1745538004763" TEXT="HeteroData_test">
<node COLOR="#435e98" CREATED="1745537946821" ID="ID_1319727141" MODIFIED="1745599992122" TEXT="HeteroData_test">
<icon BUILTIN="broken-line"/>
<node CREATED="1745595723151" ID="ID_1057941772" MODIFIED="1745596135332" TEXT="OK: hier hab ich im Test mit &#xbb;undefined behaviour&#xab; gespielt">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
&#220;berraschung: wer sich in den Fu&#223; schie&#223;t, schie&#223;t sich in den Fu&#223;
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1745596148617" ID="ID_230477037" MODIFIED="1745596185817" TEXT="der Compiler ist in keinster Weise verpflichtet, Daten im Stackframe irgendwie anzuordnen"/>
<node CREATED="1745598449798" ID="ID_1524131528" MODIFIED="1745598461412" TEXT="was will ich denn hier demonstrieren?">
<node CREATED="1745598462637" ID="ID_554868027" MODIFIED="1745598475244" TEXT="da&#xdf; der Overflow-Datenblock &#xbb;irgendwo&#xab; liegen kann"/>
<node CREATED="1745598479159" ID="ID_1513870970" MODIFIED="1745598499276" TEXT="da&#xdf; die Verzeigerung bestehen bleibt"/>
</node>
<node CREATED="1745599892391" ID="ID_1677707130" MODIFIED="1745599990906" TEXT="L&#xf6;sung: die Storage explizit vorgeben">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...ohne die implizite Annahme eines Layout, einfach indem ich den Overflow-Frame gleich per placement-New erzeuge; dann kann man trotzdem immer noch zeigen, da&#223; die Daten weiterhin in der UninitialisedStorage liegen und dort verwendet werden k&#246;nnen
</p>
</body>
</html>
</richcontent>
</node>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1745537959959" ID="ID_802122855" MODIFIED="1745538004763" TEXT="TestChainLoad_test">
<icon BUILTIN="broken-line"/>