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

“C is how the computer works” is a dangerous mindset for C programmers

words.steveklabnik.com

Post reply on HN
Print view View original

261–270 of 387 posts

Re: “C is how the computer works” is a dangerous mindset for C programmers

#261

Post by earthboundkid »

steveklabnik wrote: post #126
alharith wrote: post #113

Earlier quoted context omitted.

Just pains me that the Rust team is so oblivious to the fact that they need a spec if they ever hope to have a chance to replace C.

We are not oblivious. First of all, we are not really trying "to replace C." Second, a tremendous amount of work has been put into specifying Rust. It's just also a tremendous amount of work. Like, "the EU has given grants of millions of Euro towards working on it but we're still not done" amounts of effort. C did not have a standard for 18 years, it was first created in 1972, and ANSI C didn't appear until the sprin…

Go has a spec, which has been used to make gccgo. I'm not very familiar with other specs: is it fair to say that the Go spec is less detailed and so was able to be completed before 1.0? Is it "not a real spec" compared to ANSI C, ECMA, etc.?

Re: “C is how the computer works” is a dangerous mindset for C programmers

#262

Post by ncmncm »

saagarjha wrote: post #209
stiray wrote: post #181

Earlier quoted context omitted.

Sure, I do. I am just hooking linux kernel calls, I will never take JS for this. Pure C. Valgrind? I have a header with #define MALLOC/FREE/REALLOC/... which returns larger buffer with guards at beginning and the end while after 25 years of C I hardly do anything more problematic that this. But seriously, would you give JS developer making kernel module? Ruby? PHP? No. So I wont compare with them and I would expect t…

I'm just going to respond to the top part of your post, as it's at least somewhat relevant rather than being a disconnected rant about the kids censoring you. > I am just hooking linux kernel calls, I will never take JS for this. Pure C. Why not? Hooking native code in other languages is already fairly common: http://www.cycript.org > Valgrind? I have a header with #define MALLOC/FREE/REALLOC/... which returns larger…

It is easy for engineers, because engineers are trained to make things correctly even when that is inconvenient.

Engineers make bridges that don't collapse (unless not maintained for decades) and planes that don't fall from the sky (unless overruled by management). By the evidence, it is not easy for people who just can't be bothered to take the time to make anything correctly.

So, there are languages for engineers to use to make things where it matters if they are right, and languages for everybody else, where apparently it doesn't. Now, all we need is for engineers not to need to call into libraries not written by engineers.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#263

Post by nwmcsween »

A test for this is to code some relatively but not too simple of a program in both C and Rust using idiomatic code (don't knowingly pick some corner case for either language), compile with -O0 -g0 and be able to _understand_ the resulting output with regards to the program written. I'm not championing the use of either Rust or C and in my opinion languages should be for people not for computers.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#264

Post by saagarjha »

pizlonator wrote: post #173
jcranmer wrote: post #59

Earlier quoted context omitted.

> But C compilers are super careful to compile structured assembly style code without breaking it, even though they don’t formally promise to do so. You have never worked on a C compiler, I take it. All production compilers will at some point turn even straight-line code into a DAG and relinearize it without care to the original structure of code. Any semantics beyond that which is given in the C specification (which…

I work on compilers for a living. Structured assembly semantics are what C users in a lot of domains expect and production compilers like clang at -O3 will obey the programmer in all of the cases that are necessary to make that code work: - Aliasing rules even under strict aliasing give a must-alias escape hatch to allow arbitrary pointer casts. - Pointer math is treated as integer math. Llvm internally considers typ…

> I work on compilers for a living.

…as I take it, for languages without undefined behavior.

> Structured assembly semantics are what C users in a lot of domains expect and production compilers like clang at -O3 will obey the programmer in all of the cases that are necessary to make that code work

No, they will not, and the people working on Clang will tell you that they won't.

> Llvm internally considers typed pointer math to be equivalent to casting to int and doing math that way.

LLVM IR is not C, but I am fairly sure that it is still illegal to access memory that is outside of the bounds of an object even in IR.

> A C compiler is way more conservative about the possible outcomes of a function call or a memory store than a JS JIT for example.

Well, yes, because JavaScript JITs own the entire ABI and have full insight into both sides of the function call.

> That code isn’t wrong. It works in optimizing C compilers. The only thing wrong is the spec.

The code is wrong, and that it works today doesn't mean it won't work tomorrow. If think that all numbers ending in "3" are prime because you've only looked at "3", "13" and "23", would you say that "math is wrong" because it tells you that this isn't true in general?

Re: “C is how the computer works” is a dangerous mindset for C programmers

#266

Post by DerekL »

jcranmer wrote: post #123

One of the blog posts I keep meaning to write is in the vein of "Why C is not portable assembly." Ironically, most of my points about C failures aren't related to UB at all, but rather the fact that C's internal model doesn't comport well to important details about machines: * There's no distinction between registers and memory in C. A function parameter that is "register volatile _Atomic int" is completely legal and…

> * Missing operations such as … simultaneous div/rem

Doesn't the div function do this?

> * There's no "bitcast" operator that changes the type of a value without affecting the value. The most common workaround involves going through memory and praying the compiler will optimize that away (while violating strict aliasing semantics to boot).

> * Missing operations such as popcount, cttz, … or rotates.

Thankfully, these are coming in C++20.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#267

Post by badtuple »

jcranmer wrote: post #223
vbezhenar wrote: post #210

Earlier quoted context omitted.

Is there any low level language, which is actually close to modern x86_64?

Probably the closest you'll find today is LLVM IR (or maybe there's a slightly closer IR in some other compiler). In terms of languages you'd actually like to program yourself, Rust and C++ are slightly closer, but that's mostly a factor of trying to incorporate more hardware features rather than modelling hardware better.

Does anyone code directly in LLVM IR? I've had the thought of toying with it as a better portable assembly with a crazy optimizer behind it...but since the LLVM folk want it to be an implementation detail they warn against it due to how volatile it is across versions.

I'd be really interested to hear experiences of people who have done it though, even as a toy.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#268

Post by ncmncm »

tspiteri wrote: post #157
dooglius wrote: post #153

Earlier quoted context omitted.

That's the way I think it _should_ work, but sadly does not. For instance, see https://godbolt.org/z/ent-xp

Your code is int x; if(x == 0) foo(); if(x != 0) foo(); That is reading the uninitialized value twice. Since it is unspecified, it does not have to be consistent, so you could get the same behavior as non-zero for the first reading, and zero for the second reading. Changing your code to: int x; if(x == 0) foo(); else foo(); will give different output (same if you use !=).

A good optimizing compiler will just elide the whole code block.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#269

Post by [deleted] »

chrisseaton wrote: post #259
saagarjha wrote: post #253

Earlier quoted context omitted.

I couldn't find the verbiage for that. The standard seems to have this under undefined behavior: > The value of an object with automatic storage duration is used while it is indeterminate. But reading the value without using it seems fine?

The 'object' in this context is the storage location, not the value you read from it. You're 'using' the 'object' when you read from it.

[deleted]

Re: “C is how the computer works” is a dangerous mindset for C programmers

#270

Post by saagarjha »

chrisseaton wrote: post #259
saagarjha wrote: post #253

Earlier quoted context omitted.

I couldn't find the verbiage for that. The standard seems to have this under undefined behavior: > The value of an object with automatic storage duration is used while it is indeterminate. But reading the value without using it seems fine?

The 'object' in this context is the storage location, not the value you read from it. You're 'using' the 'object' when you read from it.

Oh, not that kind of read. I meant "read" in the context of "without actually using its value in a way that affects your program execution"–not, in what I believe the C++ term is–an ODR use. As in here: https://news.ycombinator.com/item?id=22740582
Post reply on HN