Time  Nick      Message
00:05 MTDiscord <josiah_wi> What's the UB?
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.
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: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 :)
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
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: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