I Never Thought It Would Happen To Me: I Forgot To Put "return true;" At The End Of A Function Returning Bool And Clang Just Kept Going Off The End Of The Function Into The Infinite Abyss
@mcc I have no idea why "you said this function returns a thing and you did not return the thing" was ever considered anything but a compilation error.
@mcc and I'm betting the answer is something like "it was a slight convenience for systems programmers on a computing platform that went out of production in 1982 but by the time someone pointed out that it was problematic it was already part of the language standard and we didn't want to break existing code".
@gsuberland@mcc > The rationale includes that checking if every real code path returns a value is quite difficult (without knowing which functions never return), so it's not illegal to compile a function like your example, only to actually call it like your main does.
@gsuberland@mcc "Falling off the end of a non-void function is only undefined behavior in C++, not in C. It is fairly common practice to compile C code as C++, " oh my fucking gods
@whitequark@gsuberland@mcc I remain baffled that modern compilers will happily emit a trap for UB but not provide an option to flag it as a compile-time error.
Especially since they seem to be constantly introducing exciting new UB with every compiler and/or language revision, it feels like it'd be awfully handy to learn about it at compile time rather than at runtime.
@whitequark@gsuberland@mcc On further reflection, I find this even more baffling given clang's early claim-to-fame (and big influence on gcc) of much more expressive, informative, and comprehensible errors and warnings.
@whitequark@gsuberland@mcc I was looking for a general "flag any UB as an error" flag, but I suppose assorted flags for specific situations are better than nothing.
@swetland@gsuberland@mcc there's clang-analyzer that does do that, but the false positive rate is generally too high unless you're really willing to commit to it
@swetland@whitequark@gsuberland infinite loops are UB in C++ which means that providing an error on UB in C++ would literally require solving the halting problem.
@mcc@whitequark@gsuberland I forgot about that one. Will have to update my list of "things about C++ that negatively impact my sanity."
I feel like at some point C and C++ compilers crossed over from "impressive optimization" to "so aggressive that I can't rely on my code to actually do what a straightforward read of the source says it does."
I'm probably tainted by growing up with old, dumb compilers, but I miss being able to trust the compiler to actually do what I ask it to.
@whitequark@mcc in my (admittedly limited) experience every single justification for (not) doing a thing with the c++ language standard has a counter example where they made a decision that violated that justification at some point.
more honest justifications would be "I've dug myself into a happy little rut here and now I'm personally invested in doing it this way" or "we want to fix that but it'd make extra work for the compiler devs and we'd have to put up with them complaining about it".
@gsuberland@mcc because C is the language that makes no attempt to stop you shooting your foot off. But it should at least be a warning. I don't think I've ever not gotten a warning for this... Nor had the compiler not insert a return instruction with a garbage return value. Perhaps the optimiser thinks the end is unreachable due to earlier undefined behaviour?
[[Clang, lounging on a velvet couch, its top two shirt buttons unbuttoned, smoking a cigar]] "When I see a program counter, I increment it. There's literally never a situation where that would be the wrong thing to do."
@nabijaczleweli We got it, but due to a wonky multi-step build process we didn't notice the warning until we'd noticed the problem by reading the code. The project now has a -Werror=return-type
@mcc I'm not 100% sure this is a case of "smells like undefined behaviour so the compiler just shrugs", but I am increasingly of the opinion that modern compilers that treat UB as a license to just make code just straight up fault or do absolutely random shit should provide a -werror-on-undefined-behaviour option to fail at compile time rather than runtime.
@mcc
Dear Penthouse: Long time reader, first time writer. I’d heard about undefined behavior, but never thought it could happen to me. Then one night, I met a function at a bar who whispered in my ear, “I’m not wearing a return statement,” and
@mcc@lispi314 I think it came out organically from K&R not requiring a return type, then implicating to int rather than void, but since it could be either let's not care about an existing return, etc.
Add comment