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

371–380 of 387 posts

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

#371

Post by shadowgovt »

adev_ wrote: post #368
shadowgovt wrote: post #366

Earlier quoted context omitted.

And for JavaScript, that space doesn't include buffer overruns or memory safety, unless you do something very exotic and implement your own indirected memory access in JavaScript (in which case, you've sort of dug your own grave). because undefined behavior literally means undefined behavior, C++ gets to bring to the table all of the failure modes JavaScript brings to the table in addition to the plethora of ways unc…

> But solving a problem with dynamite is still solving a problem with dynamite; there's a lot more ways it can go wrong than solving the problem with a steam drill, to torture an analogy a bit. Excepted that a language is not absolute, is not dynamite or not dynamite. It is what you do of it depending of the subset you use. C++ is not exception.

Agreed. But I won't reach for a language that lets me treat all my program's working memory as an undifferentiated integer-addressable array of bytes if I don't need that to solve the problems I'm trying to solve.

... which goes back to the topic of the HN post; that's only one way to look at the state of a running program, and it's a way that has strengths and weaknesses. The utility of it comes at the cost of the program failing in ways programs in other languages structurally cannot fail (unless you do something truly exotic, like implement a subset of a C++ compiler or interpreter in that language).

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

#372

Post by pdimitar »

pjmlp wrote: post #353
pdimitar wrote: post #219

Earlier quoted context omitted.

As your parent said, this is also an answer I can understand. Still, have you guys looked at alternatives -- and seriously evaluate them? Rust, Zig, Nim, D, others? If you tell me "we can't afford to, we have too much work" then that's also a valid answer (for a while at least).

Our alternatives are Java and .NET languages, with native bindings to C++ libraries. C++ alternatives still need to grow up to this kind of mixed language development, where I can have .NET code with C++ libraries and easily debug across them on the same Visual Studio session. Same applies to Java and C++ development experience.

Not sure how fair to newcomers (as in languages) this requirement is.

F.ex. when coding in Erlang/Elixir I can use an excellent bridging library between their VM and Rust. There's also an excellent support for working with C libraries. Not sure what else can be expected.

Maybe I am not reading you correctly and I apologise if so. It just kind of sounded like "the newer languages must be compatible with 20+ different ABI standards if they want us the older programmers working in C/C++ to adopt them"?

Back on the original topic, I completely understand if a project has too much baggage and sunk cost so as to make even a partial migration (and hardening via using memory-safe languages and/or professional paid code analysis tools) unrealistic.

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

#373

Post by pdimitar »

otabdeveloper2 wrote: post #252
pdimitar wrote: post #219

Earlier quoted context omitted.

As your parent said, this is also an answer I can understand. Still, have you guys looked at alternatives -- and seriously evaluate them? Rust, Zig, Nim, D, others? If you tell me "we can't afford to, we have too much work" then that's also a valid answer (for a while at least).

> C++ has a standard that's too long and hard to understand, so let's use a language without any standard whatsoever instead! Good lord, if that's the kind of human capital that's involved in making next-generation languages, then I have no doubt what will still be used to write serious software in 2080. (Hint: not Rust.)

You'd be more helpful if you specified what else would you deem appropriate -- as opposed to resorting to snarky sarcasm that brings nothing interesting to the discussion except supposedly degrade people whose tech choices you disagree with.

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

#374

Post by pjmlp »

pdimitar wrote: post #372
pjmlp wrote: post #353

Earlier quoted context omitted.

Our alternatives are Java and .NET languages, with native bindings to C++ libraries. C++ alternatives still need to grow up to this kind of mixed language development, where I can have .NET code with C++ libraries and easily debug across them on the same Visual Studio session. Same applies to Java and C++ development experience.

Not sure how fair to newcomers (as in languages) this requirement is. F.ex. when coding in Erlang/Elixir I can use an excellent bridging library between their VM and Rust. There's also an excellent support for working with C libraries. Not sure what else can be expected. Maybe I am not reading you correctly and I apologise if so. It just kind of sounded like "the newer languages must be compatible with 20+ different…

Naturally it isn't fair, but one cannot expect teams to drop velocity and diminish their productivity only on basis of adopting a new language that doesn't support existing workflows, IDE tooling and libraries.

It is like telling someone to delivering games in Unity and Unreal that they should use Amethyst instead, without understanding what it means to actually having a team working in those ecosystems.

Naturally Rust will get there, however it took C++ 30 years to be where it is today, and that is what any replacement attempt should take into consideration.

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

#375

Post by pdimitar »

pjmlp wrote: post #374
pdimitar wrote: post #372

Earlier quoted context omitted.

Not sure how fair to newcomers (as in languages) this requirement is. F.ex. when coding in Erlang/Elixir I can use an excellent bridging library between their VM and Rust. There's also an excellent support for working with C libraries. Not sure what else can be expected. Maybe I am not reading you correctly and I apologise if so. It just kind of sounded like "the newer languages must be compatible with 20+ different…

Naturally it isn't fair, but one cannot expect teams to drop velocity and diminish their productivity only on basis of adopting a new language that doesn't support existing workflows, IDE tooling and libraries. It is like telling someone to delivering games in Unity and Unreal that they should use Amethyst instead, without understanding what it means to actually having a team working in those ecosystems. Naturally Ru…

This is probably a much larger and not very relevant to the topic here discussion but I feel a lot of the newer breed of languages don't emphasise IDE tooling very much (not in the sense of Visual Studio / Eclipse and the like at least; VS Code gets a lot of attention though). So I fear if that's an expectation from a certain group of devs that this might already be a generational difference that's impossible to overcome.

That being said, I agree -- existing teams can't be expected to just run away to the new thing, that much is true.

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

#376

Post by saagarjha »

pizlonator wrote: post #334
saagarjha wrote: post #264

Earlier quoted context omitted.

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

There is a broad pattern of software that uses undefined behavior that gets compiled exactly as the authors of that software want. That kind of code isn’t going anywhere. You’re kind of glossing over the fact that for the compiler to perform an optimization that is correct under C semantics but not under structured assembly semantics is rare because under both laws you have to assume that memory accessed have profoun…

You say that this doesn't happen, and yet we have patches like this in JavaScriptCore: https://trac.webkit.org/changeset/195906/webkit. Pointers are hard to reason about, but 1. undefined behavior extends to a lot of things that aren't pointers and 2. compilers keep getting better at this. For example, it used to be that you could "hide" code inside a function and the compiler would have no idea what you were doing, but today's compilers inline aggressively and are better at finding this sort of thing. And it isn't just WebKit: other large projects have struggled with this as well. The compiler discarded a NULL pointer check in the Linux kernel (which I can't find a good link to, so I'll let Chris Lattner paraphrase the issue for me): http://blog.llvm.org/2011/05/what-every-c-programmer-should-... ; here's one where it crippled sanitization of return addresses in NaCl: https://bugs.chromium.org/p/nativeclient/issues/detail?id=24...

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

#378

Post by pjmlp »

pdimitar wrote: post #375
pjmlp wrote: post #374

Earlier quoted context omitted.

Naturally it isn't fair, but one cannot expect teams to drop velocity and diminish their productivity only on basis of adopting a new language that doesn't support existing workflows, IDE tooling and libraries. It is like telling someone to delivering games in Unity and Unreal that they should use Amethyst instead, without understanding what it means to actually having a team working in those ecosystems. Naturally Ru…

This is probably a much larger and not very relevant to the topic here discussion but I feel a lot of the newer breed of languages don't emphasise IDE tooling very much (not in the sense of Visual Studio / Eclipse and the like at least; VS Code gets a lot of attention though). So I fear if that's an expectation from a certain group of devs that this might already be a generational difference that's impossible to over…

Depends where you look, Swift, Kotlin and TypeScript live from their tooling.

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

#379

Post by pdimitar »

pjmlp wrote: post #378
pdimitar wrote: post #375

Earlier quoted context omitted.

This is probably a much larger and not very relevant to the topic here discussion but I feel a lot of the newer breed of languages don't emphasise IDE tooling very much (not in the sense of Visual Studio / Eclipse and the like at least; VS Code gets a lot of attention though). So I fear if that's an expectation from a certain group of devs that this might already be a generational difference that's impossible to over…

Depends where you look, Swift, Kotlin and TypeScript live from their tooling.

My favourite language -- Elixir -- is the same. I also quite admire Rust's and Golang's tooling.

CLI tooling is the best it ever was in history (from where I stand at least). But IDE tooling isn't a first class citizen for many languages these days, is what I was saying.

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

#380

Post by lmm »

madmax96 wrote: post #370
lmm wrote: post #329

Earlier quoted context omitted.

What kind of read would not constitute "using" a value? And per your previous post an object that was not initialised is indeterminate, not just unspecified. So yes, reading uninitialized memory is always UB.

A read into a character type. From 6.2.6.1¶5: >Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. ... Such a representation is called a trap representation. A read from uninitialized memory is not always UB.

What you quoted doesn't actually say anything about what happens when a trap representation is read into a character type. Such a read is still "using" the value at least in the everyday sense of the word, so in the absence of something explicitly to the contrary, as far as I can see the part of the standard that states that using an uninitialised value is UB stil applies.

Per http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_451.htm , the current standard is unclear in some respects, but the latest committee view is that that under the current standard any library function (including memcpy) may exhibit undefined behaviour when called with uninitialized memory, even when the uninitialized memory is of character type or is propagated through values of character type.

Post reply on HN