11 ms·

This is written with quite a lot of hyperbole. The predominant focus is realloc(pre,0) becoming UB instead of what the author misleadingly describes as useful,

This is written with quite a lot of hyperbole. The predominant focus is realloc(pre,0) becoming UB instead of what the author misleadingly describes as useful, consistent behaviour. It is far from that, and that’s the entire reason that it was declared UB in the first place: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf. Note that this wasn’t a proposal to change something, it’s a defect report: the original wording was never suitable. The second part is the misconception about the impact of UB. Making something UB does not dictate that its usage will initiate the rise of zombie velociraptors. It grants the implementation the power to decide the best course of action. That is, after all, what they’ve been doing all this time anyway. Note that this deviates from implementation-defined behaviour, because an implementation-defined behaviour has to be consistent. Where implementations choose to let realloc(ptr,0) summon the zombie raptors, they are free to do so. Don’t like it? Don’t target their implementation. Again, this isn’t a change from the POV of implementers - it’s a defect in the existing wording. In this case, the course of action that any implementation will choose is to stick with the status quo. It is clearly not a deciding factor in whether or not you embrace the new standard, and to suggest otherwise is dishonest, sensationalist nonsense. The feature was broken, and it’s just being named as such.

Arch-TK 4y ago
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.
- astrange 4y ago
  > 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".
  - G_z9 4y ago
    [flagged]
    - G_z9 4y ago
      [flagged]
      - SAI_Peregrinus 4y ago
        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.
      - Dylan16807 4y ago
        > How this gets downvoted is beyond me 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.
        G_z9 4y ago
        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.
c4mpute 4y ago
> The second part is the misconception about the impact of UB. [...] It grants the implementation the power to decide the best course of action. That is, after all, what they’ve been doing all this time anyway. Wrong, Wrong, Wrong. UB allows the implementation to take any arbitrary course of action, without informing anyone, without documentation, without any conscious decision, without weighing anything to be better/worse. Nondeterministically catching fire and launching nuclear rockets is a completely compliant reaction to UB. What you are describing is "implementation defined" behavior. That has to be deterministic, documented, and conforming to some definition of sanity. Examples are the binary representation of NULL, sizes of integer types or stuff like the maximum filename length. Sadly, too many things in C have "undefined behavior", too few have "implementation defined" behavior. And UB has always been an excuse for compilers to screw over programmers in hideous ways. Programmers are rightfully afraid of any kind of new UB being introduced, because it will mean that whole new classes of bugs will arise because the compiler optimized out that realloc(..., a) where a might be 0, because thats UB, so screw you and your code... And this change is especially dangerous because it makes a lot of existing code UB.
- AlotOfReading 4y ago
  I wish UB were only as nasty as "nondeterministic behavior". In fact, if there's UB in anything the compiler sees, nothing at all can be assumed, including whether you even get an output. What you've given the compiler isn't C, so it doesn't have any obligations to do anything with it. The codepath with UB doesn't have to run for the nuclear rockets to launch and the nasal demons to appear. Since approximately every nontrivial program ever written has UB, in actual practice we're only saved by the fact that compilers aren't entirely maliciously compliant.
  - coliveira 4y ago
    > approximately every nontrivial program ever written has UB You can replace "UB" for "bugs" and the result is the same. UB is a bug on the part of the programmer, from the point of view of C, similar to dereferencing a null pointer. When the standard says that something is UB, it is just clarifying what these situations are.
GuB-42 4y ago
UB can initiate the rise of zombie velociraptors. int n; printf("type 0 to stop the rise of zombie velociraptors"); scanf("%d", &n); realloc(pre, n); if (n != 0) rise_zombie_velociraptors() May result in velociraptors raising even if the user enters "0". The reason is that because realloc(pre, 0) is UB, for the compiler, it cannot happen, so n can't be 0, so the n != 0 test can be optimized out, so, velociraptors.
deleted 4y ago
[deleted]
benj111 4y ago
My understanding was that they're changing realloc() because they previously allowed zero length arrays and because you can't tell if this is a zero length array you need to either get rid of zero length arrays or change realloc(). So the feature wasn't broken to begin with, it was broken by another feature.
Asooka 4y ago
> The second part is the misconception about the impact of UB. Making something UB does not dictate that its usage will initiate the rise of zombie velociraptors. It grants the implementation the power to decide the best course of action. That is, after all, what they’ve been doing all this time anyway. Wrong. UB never happens. That is the promise the program writer makes to the compiler. UB never happens. A correct C program never executes UB. This allows the compiler to assume that anything that is UB never happens. Does some branch of your program unconditionally execute realloc(..., 0) after constant propagation? That branch never happens and can just be deleted. Reading the defect report, they state "Classifying a call to realloc with a size of 0 as undefined behavior would allow POSIX to define the otherwise undefined behavior however they please." which is wrong. UB cannot be defined, if you define it, you are no longer writing standard C. It should instead have been classified as "implementation-defined behaviour". In any case it's not that hard to just write a sane wrapper. This one is placed in the Public Domain: void *sane_realloc(void *ptr, size_t sz) { if (sz == 0) { free(ptr); /*free(NULL) is no-op*/ return NULL; } if (ptr == NULL) { return malloc(sz); } return realloc(ptr, sz); } I am calling it sane and not safe, because it is not safe. You still have the confusion of what happens when the function returns NULL (was it allocation failure or did we free the object?) - check errno. However, it has the same fully defined semantics on most all implementations and acts like people would expect. You may be tempted to make the function return the value of errno, mark it [[nodiscard]] and take a pointer-to-pointer-to-void, so that the value of the pointer will only be changed if the reallocation was successful. I am not sure if that is safer. You are trading one possible bug - null pointer on allocation failure, which then will cause a segmentation fault for another - stale pointer on allocation failure, but with updated size. The latter is more likely to be used in buffer overflow attacks than the former.
omoikane 4y ago
> This is written with quite a lot of hyperbole The first sight of "catch fire" might not have caught my attention, but by the time it got to "instrument of arson" and "Molotov cocktails", the style was sufficiently distracting that I was convinced I wasn't the intended audience.

Arch-TK 4y ago

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.

astrange 4y ago
> 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".
- G_z9 4y ago
  [flagged]
  - G_z9 4y ago
    [flagged]
    - SAI_Peregrinus 4y ago
      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.
    - Dylan16807 4y ago
      > How this gets downvoted is beyond me 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.
      - G_z9 4y ago
        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.

c4mpute 4y ago

> The second part is the misconception about the impact of UB. [...] It grants the implementation the power to decide the best course of action. That is, after all, what they’ve been doing all this time anyway. Wrong, Wrong, Wrong. UB allows the implementation to take any arbitrary course of action, without informing anyone, without documentation, without any conscious decision, without weighing anything to be better/worse. Nondeterministically catching fire and launching nuclear rockets is a completely compliant reaction to UB. What you are describing is "implementation defined" behavior. That has to be deterministic, documented, and conforming to some definition of sanity. Examples are the binary representation of NULL, sizes of integer types or stuff like the maximum filename length. Sadly, too many things in C have "undefined behavior", too few have "implementation defined" behavior. And UB has always been an excuse for compilers to screw over programmers in hideous ways. Programmers are rightfully afraid of any kind of new UB being introduced, because it will mean that whole new classes of bugs will arise because the compiler optimized out that realloc(..., a) where a might be 0, because thats UB, so screw you and your code... And this change is especially dangerous because it makes a lot of existing code UB.

AlotOfReading 4y ago
I wish UB were only as nasty as "nondeterministic behavior". In fact, if there's UB in anything the compiler sees, nothing at all can be assumed, including whether you even get an output. What you've given the compiler isn't C, so it doesn't have any obligations to do anything with it. The codepath with UB doesn't have to run for the nuclear rockets to launch and the nasal demons to appear. Since approximately every nontrivial program ever written has UB, in actual practice we're only saved by the fact that compilers aren't entirely maliciously compliant.
- coliveira 4y ago
  > approximately every nontrivial program ever written has UB You can replace "UB" for "bugs" and the result is the same. UB is a bug on the part of the programmer, from the point of view of C, similar to dereferencing a null pointer. When the standard says that something is UB, it is just clarifying what these situations are.

GuB-42 4y ago

UB can initiate the rise of zombie velociraptors. int n; printf("type 0 to stop the rise of zombie velociraptors"); scanf("%d", &n); realloc(pre, n); if (n != 0) rise_zombie_velociraptors() May result in velociraptors raising even if the user enters "0". The reason is that because realloc(pre, 0) is UB, for the compiler, it cannot happen, so n can't be 0, so the n != 0 test can be optimized out, so, velociraptors.

deleted 4y ago

[deleted]

benj111 4y ago

My understanding was that they're changing realloc() because they previously allowed zero length arrays and because you can't tell if this is a zero length array you need to either get rid of zero length arrays or change realloc(). So the feature wasn't broken to begin with, it was broken by another feature.

Asooka 4y ago

> The second part is the misconception about the impact of UB. Making something UB does not dictate that its usage will initiate the rise of zombie velociraptors. It grants the implementation the power to decide the best course of action. That is, after all, what they’ve been doing all this time anyway. Wrong. UB never happens. That is the promise the program writer makes to the compiler. UB never happens. A correct C program never executes UB. This allows the compiler to assume that anything that is UB never happens. Does some branch of your program unconditionally execute realloc(..., 0) after constant propagation? That branch never happens and can just be deleted. Reading the defect report, they state "Classifying a call to realloc with a size of 0 as undefined behavior would allow POSIX to define the otherwise undefined behavior however they please." which is wrong. UB cannot be defined, if you define it, you are no longer writing standard C. It should instead have been classified as "implementation-defined behaviour". In any case it's not that hard to just write a sane wrapper. This one is placed in the Public Domain: void *sane_realloc(void *ptr, size_t sz) { if (sz == 0) { free(ptr); /*free(NULL) is no-op*/ return NULL; } if (ptr == NULL) { return malloc(sz); } return realloc(ptr, sz); } I am calling it sane and not safe, because it is not safe. You still have the confusion of what happens when the function returns NULL (was it allocation failure or did we free the object?) - check errno. However, it has the same fully defined semantics on most all implementations and acts like people would expect. You may be tempted to make the function return the value of errno, mark it [[nodiscard]] and take a pointer-to-pointer-to-void, so that the value of the pointer will only be changed if the reallocation was successful. I am not sure if that is safer. You are trading one possible bug - null pointer on allocation failure, which then will cause a segmentation fault for another - stale pointer on allocation failure, but with updated size. The latter is more likely to be used in buffer overflow attacks than the former.

omoikane 4y ago

> This is written with quite a lot of hyperbole The first sight of "catch fire" might not have caught my attention, but by the time it got to "instrument of arson" and "Molotov cocktails", the style was sufficiently distracting that I was convinced I wasn't the intended audience.