That situation is "when you have UBSan turned on".
Yeah, I’m being downvoted by a bot or something.
Primarily because you're bringing in an argument from a different story entirely rather than figuring out a better option.
But also you're being very rude in that other thread, and calling twitter "high bandwidth" for a discussion is... weird.
> Yeah, I’m being downvoted by a bot or something.
Uh huh.
I don’t think asking for a twitter space is all that weird. I am constantly frustrated talking with people on HN because what could take 2 seconds takes 20 minutes. I often find that a debate never even has a chance to be resolved because everyone just gets worn out trying to talk through a digital straw. Plus, asking for a twitter space doesn’t involve exchange of personal information or anything concerning. It’s definitely not done and off the wall but I don’t think it’s problematic.
Edit: the more I think about it, the more sense it makes. HN has a problem with being flooded with vitriol and and lots of other negative behavior, long chains that are just useless. It would make a lot of sense to offload most of that to another platform since HN as a platform is not well suited to debating. Instead of initiating a huge chain of vitriol, a twitter space could be initiated when people want to debate something. Instead of tons of noise and garbage, HN would host a link to the space. And it would be better because the nature of a space lends itself to people coming to a conclusion, covering the issue more thoroughly and people letting loose less hate, all because of the high bandwidth, intimate nature of real-time audio. It also helps filter out people who are bots or aren’t serious or who don’t really care about the topic being debated. I am legitimately going to email HN admin about this.
But sure posting in the wrong topic will get a downvote to turn your comment gray. What is wrong with that policing?
> Are you going to downvote every comment that you see from me because some other comments I made were rude? Doesn’t really add up.
...what? You continued the thread here. Nobody is downvoting random comments of yours. Your comments on that story and this story are part of the same conversation.
And if you can't figure out how to reply in a deep thread you can just wait a couple minutes for the link to be there.
> a twitter space
Oh, the chat thing. I thought you meant tweets. Sure, that's a reasonable idea for some conversations.
> I don’t think asking for a twitter space is all that weird.
My issue is that I don't think I have anything to contribute as I'm not making original conclusions but kind of just quoting a typical labor economist. (Different from quoting the average person, they're usually worried about different things.)
Example being https://www.apricitas.io/p/chatgpt-please-take-my-job.
This is not even close to be true. Most bugs in C code are from programmer mistakes, not from UB behavior. The exaggeration that is spread by some people regarding UB is close to absurd. If something is UB, it may generate different results in different situations, even with the same compiler. The standard is just clarifying this problem. A good compiler will do something sensible, or at least issue a warning when this situation is detected. If you have a bad compiler that does strange things with your code, it's not a defect of UB but the compiler instead.
To get some insight by analogy, consider this set of constraints (unrelated to C):
x <= 7
2x >= 5
…(more with x, y, z but not more constraining x)…
When you feed UB into an optimizer, you feed a bit of lava into a plastic pipe, figuratively. You’ll get anything from program #2500…0000 to program #6999…9999, where “…” is few more thousands/millions of digits. Run some numbers from there as an .exe to see if something absurd happens.
The nature of UB and optimizers is that you either relax UBs into DBs and get worse efficiency, or you specify more UBs and get worse programming safety. What happens in between can be perceived as completely random. And the better/faster the optimizer is, the more random the outcome will likely be.
The exaggeration that is spread by some people regarding UB is close to absurd
UB-in-code is absurd by definition, no exaggeration here.
These most often lead to the triggering of UB. The reason why programmer mistakes lead to confusing bugs instead of simple and straightforward bugs which are easy to catch in the development process is mainly because UB imposes no restrictions on what the compiler should do. In the vast majority of UB cases the compilers simply don't do anything, and assume it can't happen. This is why dereferencing a pointer and then checking if it's null ends up eliding the null check (because if you've dereferenced it, it can't be null, that would be UB). Accessing past the end of an array is UB so it can't happen, therefore your compiler won't check for it. Accessing past the end of an array and accidentally reading from/writing to another variable - likewise.
UB encompasses ALL behavior for which the standard does not provide an explicit definition. The reason why the C standard provides explicit instances of UB usually boils down to clarifying situations where people were confused about whether something was UB or not. But if the behaviour is not defined in the standard, then it is by definition UB.
That being said, you're completely wrong about what UB means. Making use of UB may as well initiate the rise of zombie velociraptors. Except for the situation where your implementation explicitly specifies that it provides a predictable behaviour for a specific case of UB, there's literally no guarantee of what will happen. Assuming that the implementation will stick with some status quo and your code won't exhibit absolutely unusual behaviour is just naiive.
Please don't mislead people into thinking that it's ever a good idea to assume that undefined behaviour will be handled sensibly, this kind of mislead assumption is one of the major sources of bugs in C code.