@chrisisgr8 @hailey
Infinite loop without side-effects is UB; that said, you'd expect potential fall-through, not calling an unrelated function
Conversation
Notices
-
Embed this notice
sabik (sabik@rants.au)'s status on Monday, 01-Apr-2024 19:16:13 JST sabik -
Embed this notice
sabik (sabik@rants.au)'s status on Monday, 01-Apr-2024 19:16:04 JST sabik @rfc6919 @immibis @hailey @chrisisgr8
What a language! -
Embed this notice
💬 (rfc6919@aus.social)'s status on Monday, 01-Apr-2024 19:16:11 JST 💬 @immibis @hailey @sabik @chrisisgr8 iirc the behaviour is because the entire main() is optimised out thanks to the UB loop, then at runtime _start() jumps to where it expects main() to be
GreenSkyOverMe (Monika) repeated this. -
Embed this notice
immibis (immibis@social.immibis.com)'s status on Monday, 01-Apr-2024 19:16:12 JST immibis @sabik @chrisisgr8 @hailey in this case it looks like one part of the optimiser has noticed there's an infinite loop and removed the return instruction; another part of the optimiser has noticed there's an infinite loop and removed the infinite loop. This is allowed because C++ has some stupid rules.
I believe the intention of infinite loops being UB was to allow the compiler to remove or merge loops in general without proving they halt. -
Embed this notice
huxley(fur) 🔜 DJ@Furcationland (huxley@furry.engineer)'s status on Monday, 01-Apr-2024 19:19:35 JST huxley(fur) 🔜 DJ@Furcationland This blog post goes into why the "unreachable" function is getting called -- the compiler creates assembly that falls through: https://carette.xyz/posts/the_unreachable_code_bug/
So I think the idea is, they are defining this behavior so that this no longer happens?
GreenSkyOverMe (Monika) repeated this. -
Embed this notice
Peter Bindels (dascandy42@mastodon.social)'s status on Monday, 01-Apr-2024 19:19:35 JST Peter Bindels @huxley @sabik @chrisisgr8 @hailey I think the paper on this is proposing to make it crash reliably on that point of entering UB land, and not allowing yolo behavior.
-
Embed this notice