Time  Nick      Message
15:30 MTDiscord <luatic> irrlicht is like an onion of undefined behavior
15:32 MTDiscord <luatic> i look at the .x reader, gah it compares OOB pointers all over, might actually be problematic UB so i start fixing it, proper fix should have f64 byteswap, i need f64 -> u64 bit cast to do that nicely, i see that Irrlicht does its bit casts using the union type punning hack which works in C but is UB in C++ 🙃
15:40 MTDiscord <luatic> "FloatIntUnion32" member function "bool sign() const { return (i >> 31) != 0; }", comment says "Portable sign-extraction". truly hilarious.
15:40 sfan5     that's not allowed in C++?
15:41 sfan5     that reminds me I should check if the have typical hardening options enabled for release builds
15:42 MTDiscord <luatic> sfan5: as far as I know it's allowed in C but not in C++, reading from a different union member than the one you wrote to is UB
15:43 MTDiscord <luatic> "It is undefined behavior to read from the member of the union that wasn't most recently written." https://en.cppreference.com/cpp/language/union#Explanation
15:45 sfan5     huh
15:55 Krock     yes that's one of the annoying differences between C and C++
15:55 Krock     also the union/struct { .member = 35325 }  notation is C-exclusive (or was it added to C++ recently?)
16:02 MTDiscord <luatic> C++ 20 has it but it's more strict (iirc you can't initialize members out of order or so)
17:25 MTDiscord <jordan4ibanez> https://tenor.com/view/shrek-donkey-you-know-what-else-everybody-likes-parfaits-parfait-gif-22160776
17:26 MTDiscord <luatic> (to unconfuse the IRC users: this is in reply to "irrlicht is like an onion of undefined behavior")
20:01 sfan5     fixing the caching in the msvc workflow (broken caching is the reasong it currently takes 1h) is supposedly not that hard, in case anyone wants to bother: https://x0.at/lP8F.txt
20:02 sfan5     (AI output, in case it's not obvious)
20:04 Krock     what is this coincidence? I just looked at a failed job that took 51 minutes and the error messages makes no sense whatsoever
20:04 Krock     I suppose you could push this to a separate branch to trigger the buildbot
20:05 sfan5     I'll have a fix for the compiling itself ready soon, but I'm not bothering to fix the cache
20:05 sfan5     (github silently changed the VS version included in the runner)
20:11 sfan5     will push https://github.com/sfan5/luanti/commit/89c13b0a5c4c5623d95f55a760db04e4e5d5a8af once the run finishes
20:23 MTDiscord <rollerozxa> I was intending to do this a long time ago but forgot about it - I added a note on the old organisation page (README in a new .github repo) with a direct clickable link to the new one: https://github.com/minetest
20:30 sfan5     pushed
20:54 pgimeno   re undefined behaviour of union: my recollection was that it's also the case in C, but that GCC explicitly documents it as valid
20:56 sfan5     > It is undefined behavior to read from the member of the union that wasn't most recently written. Many compilers implement, as a non-standard language extension, the ability to read inactive members of a union.
20:56 sfan5     (cppreference about the C++ behavior)
20:57 sfan5     https://en.cppreference.com/c/language/union for C this appears to be explicitly allowed
20:57 sfan5     I vaguely remember an union being the only strictly portable way to convert function pointers in C
20:59 pgimeno   then my recollection was wrong, thanks