Live data from Hacker News

Catch-23: The New C Standard Sets the World on Fire

queue.acm.org

61–70 of 275 posts

Re: Catch-23: The New C Standard Sets the World on Fire

#61
post #41

> Pointers to free'd memory are akin to uninitialized pointers, so free(p) followed by if (p==q) is an instrument of arson What's the reason for this?

I can't tell you exactly why but it's consistent with just about everything else involving p being undefined, and the result of the comparison would be useless anyway.

Re: Catch-23: The New C Standard Sets the World on Fire

#62

Earlier quoted context omitted.

> 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.

What the standard explicitly calls out as UB is only a small subset of actual UB. While you can certainly classify all UB as "bugs", doing so misses the critical differences between UB and other categories of bugs. If you have a logic bug for example, your program will correctly and consistently do the wrong thing. It will continue doing that wrong thing with a different compiler, on a different platform today and 10…

> If you have a logic bug for example, your program will correctly and consistently do the wrong thing.

Not correct. Bugs can occur differently in different architectures, even in high level languages. UB is just a kind of bug whose effect depends on how the compiler behaves, so you have to be careful to test your code on different compiler settings. This is nothing new on programming languages, it is only made explicit in the C standard. Suddenly people started to believe that pointing out the obvious source of bugs (UB) in the standard is equivalent to let programs misbehave.

Re: Catch-23: The New C Standard Sets the World on Fire

#63
post #49

Earlier quoted context omitted.

> 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.

That's exactly why a compiler shouldn't be able to 'optimize' in the face of UB, it should be an ERROR and the section of undefined behavior highlighted in the error message.

This would mean you’d have to insert a check every time you add two signed integers together, because signed overflow is UB. You’d also have to wrap every memory access with bounds checks, because OOB memory access is UB.

There are also tons and tons of loop optimizations compilers do for side-effect free loops which would have to be removed completely. This is because infinite loops without side effects are UB. So if you wanted these optimizations you’d have to prove to the compiler — at compile time — that your loop is guaranteed to terminate since it is not allowed to assume that it will. Without these loop optimizations, numerical C code (such as numpy) would be back in the stone ages of performance.

Edit: I just wanted to point out that one of the new features in C23 is a standard library header called that includes functions for checked integer arithmetic. This allows you to safely write code for adding, subtracting, and multiplying two unknown signed integers and getting an error code which indicates success or failure. This will be the standard preferred way of doing overflow-safe math.

Re: Catch-23: The New C Standard Sets the World on Fire

#64

Earlier quoted context omitted.

> Undefined behaviour renders your entire program meaningless That's exactly the complaint. Consider that the implementations of the standard library sometimes have exposed UB: that renders behaviour of all of the running code on the system undefined. Many programmers believe that the fallout of the UB could, and therefore should, be limited in scope.

To achieve your goal, compilers would have to disable any sufficiently powerful optimization. If you write bugs (UB), a powerful compiler will eventually catch them and generate code that you didn't intend at the beginning. However, this is not the fault of the compiler or the language.

It is the fault of the language to the extent that the purpose of the language is to make it easy to write correct programs, and UB makes it really hard (and in some cases impossible) to write correct programs.

Re: Catch-23: The New C Standard Sets the World on Fire

#65

> As C89 was taking shape, the neurodivergent notion of a "zero-length object" was making the rounds I'm surprised that the authors decided to, and were able to, slip in this little euphemism.

I wonder if somewhere along the chain there was an automated tool to convert frequently abused mental-health related terms like “insane” into something leas hurtful, or something along those lines?

I haven’t seen widespread use of the word “neurodivergent” as a kind of… whatever this is, weirdly euphemistic slur, almost?

Re: Catch-23: The New C Standard Sets the World on Fire

#66
post #55

Earlier quoted context omitted.

> 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.

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 wei…

I didn't downvote you, by the way.

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.

Re: Catch-23: The New C Standard Sets the World on Fire

#67

> As C89 was taking shape, the neurodivergent notion of a "zero-length object" was making the rounds I'm surprised that the authors decided to, and were able to, slip in this little euphemism.

I wonder if somewhere along the chain there was an automated tool to convert frequently abused mental-health related terms like “insane” into something leas hurtful, or something along those lines? I haven’t seen widespread use of the word “neurodivergent” as a kind of… whatever this is, weirdly euphemistic slur, almost?

Yeah, that's pretty gross, tbh

Re: Catch-23: The New C Standard Sets the World on Fire

#68

> As C89 was taking shape, the neurodivergent notion of a "zero-length object" was making the rounds I'm surprised that the authors decided to, and were able to, slip in this little euphemism.

I wonder if somewhere along the chain there was an automated tool to convert frequently abused mental-health related terms like “insane” into something leas hurtful, or something along those lines? I haven’t seen widespread use of the word “neurodivergent” as a kind of… whatever this is, weirdly euphemistic slur, almost?

> I wonder if somewhere along the chain there was an automated tool to convert frequently abused mental-health related terms like “insane” into something leas hurtful, or something along those lines?

And yet again, these Lincoln systems mess up. While giving advice to the author can avoid Great Grimsby mistakes, making the replacements automatically is an utterly Scunthorpe decision, with failures as Slough as they are foreseeable.

If the intent is to be unhurtful, it should need to choose a different word to if the intent is to be hurtful! Even our most sophisticated automated systems are Milton Keynes at determining that kind of thing.

Re: Catch-23: The New C Standard Sets the World on Fire

#69
post #55

Earlier quoted context omitted.

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 wei…

I didn't downvote you, by the way. 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 pa…

Yes I’ve figured out the timer. As a 2010 account, I kind of have to just yield to you.

Re: Catch-23: The New C Standard Sets the World on Fire

#70
post #41

> Pointers to free'd memory are akin to uninitialized pointers, so free(p) followed by if (p==q) is an instrument of arson What's the reason for this?

I can't tell you exactly why but it's consistent with just about everything else involving p being undefined, and the result of the comparison would be useless anyway.

Why would the comparison be useless?

I can imagine situations where a pointer q might sometimes be a copy of pointer p and sometimes might point to something else, and the code wants to free q if and only if it is not a copy of p (because p has been free'd earlier).

Post reply on HN