Catch-23: The New C Standard Sets the World on Fire • Hacker News Board

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

#91

Post by coliveira » Sun, Apr 02, 2023, 3:55 AM UTC

adgjlsfhk1 wrote: post #78

coliveira wrote: post #62

Earlier quoted context omitted.

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

This has always been the case. If you write code that has UB, new compilers can do something yet undefined, by definition.

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

#92

Post by notfed » Sun, Apr 02, 2023, 3:55 AM UTC

RustyRussell wrote: post #9

Frankly, the C standards ctte went off the deep end when they effectively banned NULL to memset etc (obv with zero length). Not because these functions couldn't handle it, but because this assertion simplifies optimizations elsewhere . This has required adding extra checks in my code, found mainly by trial and error, and has made it less readable and less optimal. Finally, the checked arithmetic operations returning…

Isn't the return value just a carry bit?

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

#93

Post by hermitdev » Sun, Apr 02, 2023, 3:56 AM UTC

coliveira wrote: post #47

firstlink wrote: post #14

> and that such changes may impose themselves on old code without recompilation when dynamically linked libraries are upgraded. All I can do is laugh. This is what the dynamic linker fanatics wanted. This is what they explicitly advocate for to this day. Share and enjoy!!

Exactly! Shared libraries mean that new code with modified behavior can and will be called when made available, independent of how the original code was compiled. It is interesting that people come out to complain about this obvious behavior.

The problem isn't changing implementation. This is expected with shared libs. The problem is changing the contract of the function and then expecting it to be drop in compatible. It's not. It _should_ be treated as a breaking ABI change, because the old behavior and new behavior are not compatible, yet it's being masqueraded as such. It's quite literally the same behavior/attitude behind the "w" vs "wt" change that led to aCropolyse.

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

#94

Post by jcranmer » Sun, Apr 02, 2023, 3:59 AM UTC

tzs wrote: 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?

Given the following code:

    void *p = malloc(N);
    do_random_stuff(p);
    void *q = malloc(N);

With this rule, the compiler can conclude that p and q cannot alias, even if it doesn't have body of do_random_stuff. Without it, it would first have to prove that p is never freed before calling q, which is basically impossible (moving the body of intervening code into a different file, for example, would do the trick).

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

#95

Post by GuB-42 » Sun, Apr 02, 2023, 4:01 AM UTC

> C178 purports to be a bug-fix revision of C11. Does the word "toto" on page 1 indicate (a) the editor's musical tastes; (b) that nobody bothered to spell-check the document; (c) that we're not in Kansas anymore; or (d) none of the above?

As a french guy I'd go with (d).

I've often seen "toto" used as a placeholder name, sometimes followed by "titi", "tata", "tutu", I have even used it myself. It is similar to "foo", "bar", "baz". I don't know if it is specific to France, of French speaking countries, but it is definitely a thing here.

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

#96

Post by ludocode » Sun, Apr 02, 2023, 4:06 AM UTC

juunpp wrote: post #37

> The ckd_* macros steer a refreshingly sane path around arithmetic pitfalls including C's "usual arithmetic conversions." A 7 letter function to add two numbers and that returns a boolean... not entirely sure I'd call that 'sane'.

I'd prefer if it were more letters. It bothers me when API designers omit random letters just to save a few keystrokes. These are particularly egregious because I keep forgetting which letters they kept. Is it "chk"? or "ckd"? or "chd"? or something else?

I wrote a portability library that wraps these with compiler intrinsic and standard C fallbacks. I chose to spell out the full word in addition to making the type explicit. It's a lot more verbose of course but a lot clearer to read:

https://github.com/ludocode/ghost/blob/develop/include/ghost...

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

#97

Post by ternaryoperator » Sun, Apr 02, 2023, 4:08 AM UTC

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…

This reminds me of a point made by the late Stan Kelly-Bootle, who for years wrote the Devil's Advocate column in UNIX Review magazine. In the early 1990s, he was discussing Microsoft's new C compiler and noted that in the promo material for the new compiler, it showed a benchmark for a loop that counted from 1 to 10,000 then printed "Hello". MS claimed that without optimization it took a few milliseconds, after optimization: 0 ms. A small asterisk explained the optimizer simply removed the loop. Kelly-Bootle pointed out, that the only reason a developer would write such a loop was to introduce a needed delay. Therefore, deleting the loop was not optimizing, but in fact pessimizing. And so, it was in fact Microsoft's Pessimizing C compiler.

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

#98

Post by goatlover » Sun, Apr 02, 2023, 4:20 AM UTC

ludocode wrote: post #96

juunpp wrote: post #37

> The ckd_* macros steer a refreshingly sane path around arithmetic pitfalls including C's "usual arithmetic conversions." A 7 letter function to add two numbers and that returns a boolean... not entirely sure I'd call that 'sane'.

I'd prefer if it were more letters. It bothers me when API designers omit random letters just to save a few keystrokes. These are particularly egregious because I keep forgetting which letters they kept. Is it "chk"? or "ckd"? or "chd"? or something else? I wrote a portability library that wraps these with compiler intrinsic and standard C fallbacks. I chose to spell out the full word in addition to making the type e…

A saner language would handle the conversion for you so it would work with just the normal math operators.

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

#99

Post by jcranmer » Sun, Apr 02, 2023, 4:21 AM UTC

adgjlsfhk1 wrote: post #76

coliveira wrote: post #73

Earlier quoted context omitted.

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

> 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

The second half of the sentence doesn't follow from the first. Take everyone's favorite example, signed integer overflow: all you have to do to avoid UB on signed integer overflow is check for overflow before doing the operation (and C23 finally adds features to do that for you).

Taking a step back, the fundamental thing about UB is that it is very nearly always a bug in your code (and this includes especially integer overflow!). Even if you gave well-defined semantics to UB, the semantics you'd give would very rarely make the program not buggy. Complaining that we can't prove programs free of UB is tantamount to complaining that we can't prove programs free of bugs.

It actually turns out that UB is actually extremely helpful for tools that try to help programmers find bugs in their code. Since UB is automatically a bug, any tool that finds UB knows that it found a bug; if you give it well-defined semantics instead, it's a lot trickier to assert that it's a bug. In a real-world example, the infamous buffer overflow vulnerability Heartbleed stymied most (all?) static analyzers for the simple reason that, due to how OpenSSL did memory management, it wasn't actually undefined behavior by C's definition. Unsigned integer overflow also falls into this bucket--it's very hard to distinguish between intentional cases of unsigned integer overflow (e.g., hashing algorithms) from unintentional cases (e.g., calculating buffer sizes).

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

#100

Post by nimish » Sun, Apr 02, 2023, 4:31 AM UTC

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.

It's still apt, even as someone ostensibly in that category.

It does require some abstract thinking to comprehend sets of zero measure, negative measure or complex measure in mathematics. A "zero length object" is also encountered pretty often in practice:http://docs.autodesk.com/CIV3D/2013/ENU/index.html?url=files... and zero-length files come to mind.

The euphemism ends up working out fine, though likely not the author's intent.