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

151–160 of 275 posts

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

#151

Post by masklinn »

goatlover wrote: post #98
ludocode wrote: post #96

Earlier quoted context omitted.

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.

How would that work for the largest type supported by the platform?

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

#152

Post by xigoi »

jcranmer wrote: post #99
adgjlsfhk1 wrote: post #76

Earlier quoted context omitted.

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…

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

…making your code practically unreadable, since you have to write ckd_add(ckd_add(ckd_mul(a,a),ckd_mul(ckd_mul(2,a),b)),ckd_mul(b,b)) instead of a * a + 2 * a * b + b * b.

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

#153

Post by lionkor »

GuB-42 wrote: post #90

I actually like unreachable() a lot. What it does is that it invokes undefined behavior, that's all. It does nothing trickier than any other kind of UB. In fact, I could implement unreachable() like this: void unreachable() { (char *)0 = 1; }. Standardizing it however gives interesting options for compilers and tool writers. The best use I can find is to bound the values of the argument of a function. For example, if…

Respectfully, you would already be doing this in any C codebase, with `assert()`, right? We are all checking our preconditions with assert... right?

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

#154

Post by adrian_b »

chongli wrote: post #118
DangitBobby wrote: post #112

Earlier quoted context omitted.

Another option would be to define behaviors for integer overflow and out of bounds memory access. Presumably they happen fairly often and it might be a good idea to nail down what should happen in those cases.

Those things aren’t up to the language, they’re up to hardware. C is a portable language that runs on many different platforms. Some platforms might have protected memory and trap on out of bounds memory access. Other platforms have a single, flat address space where out of bounds memory access is not an error, it just reads whatever is there since your program has full access to all memory. The same goes for integer…

The problem is that here is a vicious circle.

Most old computer architectures had a much more complete set of hardware exceptions, including cases like integer overflow or out-of-bounds access.

In modern superscalar pipelined CPUs, implementing all the desirable hardware exceptions without reducing the performance remains possible (through speculative execution), but it is more expensive than in simple CPUs.

Because of that, the hardware designers have taken advantage of the popularity gained by languages like C and C++ and almost all modern programming languages, which no longer specify the behavior for various errors, and they omit the required hardware means, to reduce the CPU cost, justifying their decision by the existing programming language standards.

The correct way to solve this would have been to include in all programming language standards well-defined and uniform behaviors for all erroneous conditions, which would have forced the CPU designers to provide efficient means to detect such conditions, like they are forced to implement the IEEE standard for floating-point arithmetic, despite their desire to provide unreliable arithmetic, which is cheaper and which could win benchmarks by cheating.

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

#155

Post by gpderetta »

DangitBobby wrote: post #112
chongli wrote: post #63

Earlier quoted context omitted.

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

Another option would be to define behaviors for integer overflow and out of bounds memory access. Presumably they happen fairly often and it might be a good idea to nail down what should happen in those cases.

Good luck defining the behaviour of use after free of accessing out of bound stack memory without bound checking and GC.

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

#156

Post by pjmlp »

Gibbon1 wrote: post #124
chongli wrote: post #33

Earlier quoted context omitted.

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.

Until LLVM, GCC, key game engines and GPGPU SDK get rewritten into something else, it is going to be Resident Evil day for a looong time.

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

#157

Post by gpderetta »

mjevans wrote: post #49
coliveira wrote: post #44

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.

We rehash this argument every few weeks. Please search the comment history why it is nonsensical.

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

#158

Post by rahen »

GuB-42 wrote: post #95

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

Most likely toto as the French for foobar.

Jens Gustedt is part of the C comity and participated to C23. He also works for INRIA in France: https://en.wikipedia.org/wiki/French_Institute_for_Research_...

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

#159

Post by quintussss »

I always wonder how much these new C standards use, as C is now mostly used in areas where one is severely limited when it comes to compiler choice. Where I work, we use GCC 6.2 and iso9899:1990 (C90). If we were able to use a modern compiler, we would probably just use C++.

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

#160

Post by pjmlp »

masklinn wrote: post #151
goatlover wrote: post #98

Earlier quoted context omitted.

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

How would that work for the largest type supported by the platform?

A panic would be thrown, like in memory safe system programming languages, those that were in use outside Bell Labs and unfortunely lost to UNIX.
Post reply on HN