Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

queue.acm.org

Post reply on HN
Print view View original

51–60 of 275 posts

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

#51

Post by wahern »

Dylan16807 wrote: post #32

> C23 furthermore gives the compiler license to use an unreachable annotation on one code path to justify removing, without notice or warning, an entirely different code path that is not marked unreachable: see the discussion of puts() in Example 1 on page 316 of N3054.9 I don't agree with that description at all. Here's the code: 1 if (argc The only code path that's "entirely different" is lines 1,4,5 and in that ca…

I think the point is that if the `argc always greater than 2, permitting the compiler to optimize the entire block to just:

  return printf("%s: we see %s", argv[0], argv[1]);
IOW, the conditional has been elided. But you're right in that the wording of the complaint doesn't match the example. The author presumably had in mind some of the more infamous NULL pointer-related optimizations, without spending the time to put together a properly analogous example.

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

#52

Post by SAI_Peregrinus »

G_z9 wrote: post #46
G_z9 wrote: post #42

Earlier quoted context omitted.

[flagged]

[flagged]

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.

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

#53

Post by Dylan16807 »

G_z9 wrote: post #46
G_z9 wrote: post #42

Earlier quoted context omitted.

[flagged]

[flagged]

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

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

#55

Post by G_z9 »

Dylan16807 wrote: post #53
G_z9 wrote: post #46

Earlier quoted context omitted.

[flagged]

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

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

#56

Post by AlotOfReading »

coliveira wrote: post #44
AlotOfReading wrote: post #23

Earlier quoted context omitted.

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…

> 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 years from now. Implementation defined behavior is a bit looser, but will still be consistent with any particular implementation (which will document the behavior) and will only manifest in the code that depends on it. A PR inserting one of these "normal" bugs doesn't invalidate the entire rest of the program.

UB is different. You can't make assumptions about UB because from the point of view of the standard, UB is "not C". There are no assumptions to be made, it's just all the stuff that doesn't have assigned semantics. And since the input is meaningless, so is the entirety of whatever the compiler gives you back.

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

#57

Post by chongli »

coliveira wrote: post #45
Joker_vD wrote: post #39

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.

Compiler writers have already done this. With flags you can disable any optimization you like, with all of the performance loss that entails. But then people complain that their programs are slow.

What people really want is an AI that ignores the code they write and just “does what they really meant.” But of course that’s not foolproof either. Every day people ask each other to do things and miscommunications occur, with the wrong thing being done. I don’t really know what to say other than “people should be more careful and also more forgiving.”

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

#58

Post by coliveira »

peppermint_gum wrote: post #30
wahern wrote: post #6

Earlier quoted context omitted.

> Seems a bit tone deaf to create new undefined behavior in memory handling, It's only tone deaf to people who understand "undefined behavior" as an epithet or as synonymous with giving a license to compilers to screw you over. The term doesn't have either of those meaning to those on the C committee. In fact, one of the explicit rationales for the proposal is that, "Classifying a call to realloc with a size of 0 as…

>It's only tone deaf to people who understand "undefined behavior" as an epithet or as synonymous with giving a license to compilers to screw you over. The term doesn't have either of those meaning to those on the C committee. It's unfortunate but not surprising that the C committee isn't aware of the problems with the undefined behavior. In fact, after I started reading WG14 meetings minutes, I completely lost faith…

This is not a problem with the committee and is not a problem with compiler writers. The committee is only marking certain behaviors as UB. Compilers can do what they think is more sensible in these situations. And compiler writers are not forcing you to accept these extreme optimizations. You always have the option of disabling optimizations and accept that your code has bugs (UB). You just need to test the code you write under different compiler settings, similarly to how you test code in different environments.

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

#59

Post by SAI_Peregrinus »

wruza wrote: post #34
ericpauley wrote: post #12

Earlier quoted context omitted.

> Finally, the checked arithmetic operations returning false on success is a horror show. This seems in line with C conventions? Generally a 0 return code means success.

With int statuses, not with bools. It’s just a twisted logic in return value you have to deal with in your head. “If checked operation has a status, then it failed.” - ok “If checked operation [is true], then it failed.” - wat

The checked operations ask "did an error occur?". If it's false, then the check passed and no error occurred. If it's true, then the check indicated an error.

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

#60

Post by wruza »

coliveira wrote: post #40
Arch-TK wrote: post #5

Earlier quoted context omitted.

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

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

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

Post reply on HN