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

121–130 of 275 posts

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

#121

Post by ChancyChance »

notfed wrote: post #88
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.

It's a flaw that has a pretty good tradeoff: unparalleled readability.

It depends. If you want to study maths, yes. If you want to be a programmer:

[status, value] = add(a, b);

Is much more unparalleled-ly (?) readable from the perspective of how a computer actually operates. In reality, this:

uint c = (uint)a + (uint)b; // (to make that other guy happy)

is really:

c = (a + b) % (sizeof(uint));

in "C", which is less readable but far more accurate.

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

#124

Post by Gibbon1 »

chongli wrote: post #33
adgjlsfhk1 wrote: post #25

Earlier quoted context omitted.

the thing that makes UB almost malicious is that it propagates inter-procedurally. This makes reasoning about code with UB basically impossible which means that you should always assume that the compiler is going to screw you over if you use it because there is no way to know whether it will.

You should consider a program with undefined behaviour to be the equivalent of a mathematical proof that contains an unstated contradiction. Ex falso quodlibet : from a falsehood anything follows. Also called the principle of explosion. Undefined behaviour renders your entire program meaningless. It must be avoided at all costs. Using undefined behaviour on purpose is like sticking a fork in an electrical socket.

That's not an argument to keep live grenades laying around, it's an argument to remove them from the spec.

Like signed int being UB. Define it to have 2 complement semantics. Problem solved. I'm sure the nutters trying to extend C++ with templates will howl but this is C not C++. And seriously C++ is dead man walking at this point.

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

#125

Post by codeflo »

ternaryoperator wrote: post #97
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 opti…

Of course, that's technically incorrect. The way the standards are written, the compiler is free to replace the program with any other program that has the same (in a precisely defined sense) observable behavior (these are the famous "as if" formulations in language specs). Heating up the CPU is not considered observable behavior.

If someone really just wants a delay, it's easy to either (for programs running on normal OSs) call a sleep function, or (on tiny embedded systems) add an empty inline assembler statement that the compiler can't see through.

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

#126

Post by codeflo »

_8j50 wrote: post #113
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…

Shouldn't the compiler warn or error on unreachable code?

This is not about code that's found to be unreachable through static analysis (where compilers might warn), but about a manual programmer annotation that claims the code is dynamically unreachable even though statically it might look otherwise.

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

#127

Post by JonChesterfield »

c4mpute wrote: post #13
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.

First, you might have meant c = a+b; The other way isn't really definable as an assignment mathematically. And there is a lot more to it than just pass/fail. First, an addition doesn't fail, from a computer architecture perspective, the addition will always succeed, the only thing that could fail (in all the usual architectures) are possible memory fetch and store operations when not strictly dealing in register or i…

> The other way isn't really definable as an assignment mathematically.

It's an equality sign. See also, := and unification.

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

#128

Post by JonChesterfield »

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

Compilers do this sort of range tracking anyway. At least within a function. It's useful for loop optimisations.

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

#129

Post by JonChesterfield »

RobotToaster wrote: post #29
GianFabien wrote: post #21

Maybe I'm being dense. To me it appears that the standards are telling compiler writers what should be done. In doing so the compilers will become ever more complex and thus bug-prone. I learnt C back when K&R (first edition) was the reference. Ok, it was hardly much more than a universal assembler to make every computer look like a PDP-11. In my experience C is the language to use when you want to be close to the me…

>To me it appears that the standards are telling compiler writers what should be done. Isn't that what standards are supposed to do?

Traditionally they recorded existing practice and gently encouraged diverging implementations to converge.

The alternative approach is to invent things by committee, hopefully with some implementers watching, and hope for the best.

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

#130

Post by JonChesterfield »

Dwedit wrote: post #20

Did we ever legalize type punning?

We have "pointer provenance" which allows license to track type punning across more of your program than ever before in order to delete more parts of it with no diagnostic required.

For bonus marks, int and atomic_int are unrelated types, and simd vector types aren't a thing, so enjoy the unfixable performance cost of choosing C.

Post reply on HN