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

71–80 of 275 posts

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

#71

Post by coliveira »

chongli wrote: post #57
coliveira wrote: post #45

Earlier quoted context omitted.

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

Exactly. All the hoopla about UB is complaining about how compiler optimizations work and the fact that the standard committee makes clear (with each new meeting) what is considered undefined behavior or not. They should instead thank the committee for clarifying this.

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

#72

Post by shagie »

wizzwizz4 wrote: post #68
bee_rider wrote: post #65

Earlier quoted context omitted.

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

As an aside, this is one of the spots where GPT does a really good job of fixing things.

    Reword the following passage.  Change euphemisms to wording that has similar meaning though no negative conotations.  Indicate changed words by putting them in "{{word}}"
    ###
    Standards are supposed to lead
    ...
    Why are such requests made? Often because of arithmetic bugs. And what is a non-null pointer from malloc(0) good for? Absolutely nothing, except shooting yourself in the foot.
    ###
To which it returned:

    Standards are meant to provide the groundwork for a better world by enabling code portability. Real standardization necessitates {{managing}} a variety of compiler and library implementations while maintaining sensible rules. The saga of the realloc story demonstrates that C standardization does not operate in this fashion any longer.

    As C89 was being crafted, there was a {{unconventional}} thought of a "zero-length object": Supporters proposed that a non-null pointer to such an object should be given for requests for zero-byte allocation.

    Why do such requests come about? Frequently due to miscalculations. And what is a non-null pointer from malloc(0) useful for? Nothing, apart from {{setting oneself up for failure}}.
It changed (along with some wording around to make the changes fit):

heading cats -> managing

neurodivergent -> unconventional

shooting yourself in the foot -> setting oneself up for failure

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

#73

Post by coliveira »

adgjlsfhk1 wrote: post #64
coliveira wrote: post #45

Earlier quoted context omitted.

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.

It is just the opposite. UB is a clarification to tell programmers what the language considers to be undesired behavior. If they didn't say anything, it would be always a mystery if a certain construct was allowed or not, effectively making it compiler dependent. Compilers would also have less avenue for creating optimizations. In the next iterations of the C standard we may see more constructs classified as UB.

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

#74

Post by [deleted] »

Arch-TK wrote: post #8
ChancyChance wrote: post #4

Is the world finally realizing that "a + b" actually returns two values: pass/fail and the value if pass? "a + b = c;" is a fundamentally flawed operation from a computer architecture perspective.

There is actually another option. A more sophisticated type system. Let's say you had some pseudocode like this: let a = 5 let b = 12 let c = a + b The type of a would be Integer[5..5], the type of b would be Integer[12..12], the type of c would therefore be Integer[17..17]. In a more complex example: def foo(a: Integer[0..10], b: Integer[0..10]): return a + b The return type of this function would be Integer[0..20].…

[deleted]

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

#75

Post by Dylan16807 »

tzs wrote: post #70
Dylan16807 wrote: post #61

Earlier quoted context omitted.

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

Because a new object can have the same address as p, so comparing to p isn't enough to tell you if you have a copy of p or a live pointer to something else.

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

#76

Post by adgjlsfhk1 »

coliveira wrote: post #73
adgjlsfhk1 wrote: post #64

Earlier quoted context omitted.

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.

It is just the opposite. UB is a clarification to tell programmers what the language considers to be undesired behavior. If they didn't say anything, it would be always a mystery if a certain construct was allowed or not, effectively making it compiler dependent. Compilers would also have less avenue for creating optimizations. In the next iterations of the C standard we may see more constructs classified as UB.

That sounds good in theory, but many things that are UB in C/C++ are UB because they are really hard to verify at compile time which makes them almost impossible to program around. Any signed addition in C is potential UB unless you have a proof that all numbers that will ever be input to the addition won't cause overflow (which is made harder because C doesn't define the size of the default integer types). Furthermore, no progress is UB which means that as a programmer, you have to solve the halting problem for your program before knowing whether it has a bug.

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

#77

Post by chongli »

bee_rider wrote: post #65
MatmaRex wrote: post #54

> 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 haven’t seen widespread use of the word “neurodivergent” as a kind of… whatever this is, weirdly euphemistic slur, almost?

It’s a continuation of the euphemism treadmill [1]. It won’t be long before “neurodivergent” is considered politically incorrect and a new term is invented to replace it.

[1] https://www.urbandictionary.com/define.php?term=Euphemism%20...

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

#78

Post by adgjlsfhk1 »

coliveira wrote: post #62
AlotOfReading wrote: post #56

Earlier quoted context omitted.

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

> you have to be careful to test your code on different compiler settings.

The problem is you have to test your code on compilers that don't exist yet with compiler settings that do different things from any compiler that ever might exist.

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

#79

Post by dtolnay »

wahern wrote: post #51
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 pu…

I interpreted the author's characterization to be about something like:

  1  if (argc
in which not just lines 4-6,8 go away (as you said) but also lines 1-2.

It makes sense to me but I can see why the author would characterize this situation as "license to use an unreachable annotation on one code path to justify removing an entirely different code path that is not marked unreachable". In a different world one might expect A to be printed "before the UB happens".

Post reply on HN