I agree that realloc was poorly defined for the 0 size case, I think UB or IDB both would have worked in this case to really drive that point home, the WG chose 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.
> this kind of mislead assumption is one of the major sources of bugs in C code.
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.
Optimizing compilers don’t work like that. They can either deviate from the standard and leave it as defined behavior, or mark it UB and go with it as usual.
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 this to a linear constraint solver, you may get anything from 2.5 to 7 as x. E.g. 3.1415926. Not because a solver wanted to draw some circles, but because it transformed your geometric problem into an abstract representation for its own algorithm, performed some fast operations over it and returned the result. Nobody knows how exactly a specific solving method will behave wrt (underconstrained) x given that the description above is all you have.
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.
> Most bugs in C code are from programmer mistakes
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.
Right, this should have been left to the implementor if they didn't want to standardize one behavior. Making it UB is the worst possible outcome. Yes, people who write portable code will still want to not rely on `realloc()`'s freeing behavior, but if you do and your realloc() implementation doesn't, then you suffer a leak, while if you do and realloc() decides to wipe your drive and make your power supply explode...
> 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.
That situation is "when you have UBSan turned on".
Ok, that’s not unreasonable. But I think that making an unrelated comment like that is really only a bad thing if it’s in bad faith. He made that comment expecting a response, I’m not like hounding him. And yes, I said some rude things. 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. And why are you policing the threads? That’s more weird than asking for a twitter space.
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.
Hey, I think getting into arguments for a day then randomly giving up and wandering off is what the sites all about. Actually, I think the guy who stops replying first kind of wins - it's similar to why you shouldn't double-text when dating.
> 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.)
It's not directly related to the topic at hand. It's meta-commentary about the discussion, not about the actual topic. That, and your post I'm replying to, and this reply I'm making should all be downvoted as they're all off-topic.
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.