| Time |
Nick |
Message |
| 00:05 |
MTDiscord |
<josiah_wi> What's the UB? |
| 00:08 |
|
SFENCE joined #luanti-dev |
| 00:11 |
[MatrxMT] |
<Zughy> I guess undefined behaviour |
| 00:12 |
MTDiscord |
<josiah_wi> Sorry, I was asking about what case of undefined behavior it falls under. |
| 00:14 |
|
SFENCE joined #luanti-dev |
| 01:02 |
|
SFENCE joined #luanti-dev |
| 01:36 |
|
SFENCE joined #luanti-dev |
| 02:09 |
|
SFENCE joined #luanti-dev |
| 02:19 |
|
SFENCE joined #luanti-dev |
| 02:33 |
|
SFENCE joined #luanti-dev |
| 03:04 |
|
SFENCE joined #luanti-dev |
| 03:49 |
|
GreenXenith joined #luanti-dev |
| 03:57 |
|
SFENCE joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 04:20 |
|
SFENCE joined #luanti-dev |
| 04:35 |
|
SFENCE joined #luanti-dev |
| 05:08 |
|
SFENCE joined #luanti-dev |
| 05:31 |
|
SFENCE joined #luanti-dev |
| 05:59 |
|
SFENCE joined #luanti-dev |
| 06:27 |
|
hwpplayer1 joined #luanti-dev |
| 06:39 |
|
SFENCE joined #luanti-dev |
| 07:16 |
sfan5 |
"taking the address of one array member to get to the next" looks fishy |
| 07:17 |
sfan5 |
not sure if the standard allows inserting padding |
| 07:18 |
|
SFENCE joined #luanti-dev |
| 07:26 |
sfan5 |
no problems generating effective code here: https://godbolt.org/z/6KbPqKsx6 |
| 07:28 |
sfan5 |
s/array member/class member/ actually. wouldn't be fishy at all with array members :) |
| 07:29 |
|
hwpplayer1 joined #luanti-dev |
| 08:19 |
|
hwpplayer1 joined #luanti-dev |
| 12:22 |
MTDiscord |
<josiah_wi> Ah, yeah, the standard allows padding in structs (with some rules IIRC). |
| 13:10 |
MTDiscord |
<luatic> As far as I know &s or &s.x does not guarantee that usage as a many-item pointer works, even if all struct fields are of the same type, and I can imagine this breaking based on how the struct is laid out in memory. |
| 13:10 |
MTDiscord |
<luatic> An unfortunate (non-array-like) layout for things like v3f is unlikely, and probably fixable using compiler directives (like packed), so I'm not very concerned about this. |
| 13:20 |
sfan5 |
could just add some static_asserts if this is important |
| 13:21 |
sfan5 |
that assumes the compiler won't use this UB to do incorrect optimizations |
| 13:26 |
sfan5 |
hmm however if you dont have a compile-time constant the codegen gets worse https://godbolt.org/z/Kr6PeT9GT |
| 13:27 |
MTDiscord |
<luatic> yeah incorrect optimizations is what i'm more worried about. is the compiler not allowed to assume that if we only take a reference to v.X, we can only mess with v.X? |
| 13:27 |
sfan5 |
not sure |
| 13:28 |
MTDiscord |
<luatic> anyways i looked at our usages of these operators |
| 13:28 |
MTDiscord |
<luatic> they're basically all in loops where i = 0, 1, 2 |
| 13:28 |
sfan5 |
if the X, Y, Z names didn't matter we could turn the members into a T[3] |
| 13:28 |
sfan5 |
but they do |
| 13:28 |
sfan5 |
so 🤷 |
| 13:28 |
sfan5 |
I guess we should use my proposed implementation for safety? |
| 13:29 |
sfan5 |
ah great we even already have CODE_UNREACHABLE() in irrlicht |
| 13:29 |
MTDiscord |
<luatic> i think we could turn this into a template thing and force i to be a compile-time constant |
| 13:29 |
sfan5 |
that would break the loops |
| 13:30 |
MTDiscord |
<luatic> we would probably need to write the loops as recursive templates or something |
| 13:30 |
MTDiscord |
<luatic> because c++ has no good syntax for "constexpr loops" |
| 13:31 |
sfan5 |
time to switch to rust |
| 13:32 |
MTDiscord |
<luatic> i was having zig in mind ;) |
| 13:36 |
MTDiscord |
<luatic> actually there is something funny we could do |
| 13:38 |
MTDiscord |
<luatic> consider: float f = 42; float v3f::*cs[3] = {&v3f::x, &v3f::y, &v3f::z}; for (int i = 0; i < 3; ++i) v.*cs[i] = f; |
| 13:47 |
sfan5 |
if you try that with pointers you get what you asked for, but in assembly https://godbolt.org/z/qejcxMerc |
| 13:54 |
sfan5 |
FWIW our extended vertex types are also UB because there is no guarantee about member order for non-POD types |
| 13:54 |
sfan5 |
so offsetof becomes invalid too |
| 13:56 |
MTDiscord |
<wsor4035> i am semi curious on what (active) core devs thoughts/sentiments are regarding adding another language such as rust/zig to luanti |
| 13:56 |
sfan5 |
the trouble is not worth it |
| 13:57 |
sfan5 |
also depending on what exact parts you expect the new language to be used in we may end up spending significant time just writing bindings between C++ and <new lang> |
| 13:58 |
MTDiscord |
<wsor4035> thats why i listed zig/rust since with zig you can just compile c/c++ without caring about bindings, while with rust, can use extern c. but yeahs for other langauges probably would have to do more bindings/ffi/etc |
| 14:00 |
|
SFENCE joined #luanti-dev |
| 14:26 |
|
SFENCE joined #luanti-dev |
| 14:43 |
|
hwpplayer1 joined #luanti-dev |
| 14:45 |
|
SFENCE joined #luanti-dev |
| 15:07 |
|
TheCoffeMaker_ joined #luanti-dev |
| 15:22 |
|
SFENCE joined #luanti-dev |
| 15:47 |
|
SFENCE joined #luanti-dev |
| 16:01 |
|
cx384 joined #luanti-dev |
| 16:17 |
|
[MatrxMT] joined #luanti-dev |
| 16:20 |
|
SFENCE joined #luanti-dev |
| 16:25 |
cx384 |
Merging #15978 #15931 #15930 and #15967 in 15 min |
| 16:25 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15978 -- Set `CMAKE_POLICY_VERSION_MINIMUM=3.5` to make MSVC CI work again by appgurueu |
| 16:25 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15931 -- Add delay between punching and digging node by ryvnf |
| 16:25 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15930 -- Draw node animation for items by cx384 |
| 16:25 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15967 -- Move client code out of ItemDefManager by cx384 |
| 16:43 |
|
SFENCE joined #luanti-dev |
| 16:45 |
cx384 |
Regarding wsor4035 question, in my opinion, using languages like rust/zig in the engine is not worth it, the time is better spent elsewhere. |
| 16:45 |
cx384 |
If you start a new project like e.g. minetestmapper which doesn't end up in the Luanti binary you could use another language. |
| 16:58 |
cx384 |
merged |
| 17:03 |
|
SFENCE joined #luanti-dev |
| 17:10 |
|
SFENCE joined #luanti-dev |
| 17:17 |
|
SFENCE joined #luanti-dev |
| 17:20 |
|
turtleman joined #luanti-dev |
| 17:37 |
|
SFENCE joined #luanti-dev |
| 17:45 |
|
hwpplayer1 joined #luanti-dev |
| 17:50 |
|
SFENCE joined #luanti-dev |
| 18:44 |
|
Desour joined #luanti-dev |
| 19:08 |
|
SFENCE joined #luanti-dev |
| 19:25 |
|
exoticalexo joined #luanti-dev |
| 19:42 |
|
SFENCE joined #luanti-dev |
| 19:47 |
|
exoticalexo12 joined #luanti-dev |
| 19:49 |
|
exoticalexo54 joined #luanti-dev |
| 19:50 |
|
exoticalexo11 joined #luanti-dev |
| 19:52 |
|
exoticalexo joined #luanti-dev |
| 20:05 |
|
exoticalexo joined #luanti-dev |
| 20:25 |
|
exoticalexo57 joined #luanti-dev |
| 20:53 |
|
exoticalexo joined #luanti-dev |
| 21:06 |
|
SFENCE joined #luanti-dev |
| 21:57 |
|
SFENCE joined #luanti-dev |
| 22:28 |
|
SFENCE joined #luanti-dev |
| 22:32 |
|
panwolfram joined #luanti-dev |
| 23:10 |
|
SFENCE joined #luanti-dev |
| 23:44 |
|
SFENCE joined #luanti-dev |
