| Time |
Nick |
Message |
| 00:14 |
|
Pexin joined #luanti-dev |
| 00:59 |
|
YuGiOhJCJ joined #luanti-dev |
| 03:34 |
|
swags joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 05:43 |
|
ivanbu joined #luanti-dev |
| 08:05 |
|
pgimeno joined #luanti-dev |
| 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") |
| 17:46 |
|
Desour joined #luanti-dev |
| 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 |
| 22:09 |
|
Sokomine joined #luanti-dev |
| 22:33 |
|
panwolfram joined #luanti-dev |
| 23:33 |
|
YuGiOhJCJ joined #luanti-dev |
