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

321–330 of 387 posts

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

#321

Post by myrrlyn »

yjftsjthsd-h wrote: post #283
rhinoceraptor wrote: post #215

Earlier quoted context omitted.

OpenBSD has almost a singular focus on security, and even they have vulnerabilities. If they can't write safe C 100% of the time, what hope does anyone else have?

So... Is there an OS with zero vulnerabilities written in Rust/Go/Ada/anything that I should know about? If nobody's written safe Rust/Go/Ada/whatever 100% of the time, what hope do I have? Now, I think that particular argument is poor. The more defensible version would be to look at the proportion of errors that occurred in C that would not occur in your language of choice, versus the number of errors that occur in…

Redox[0] actively wants to hear your vulnerability reports.

[0]: https://www.redox-os.org/

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

#322

Post by amiga_500 »

saagarjha wrote: post #273
amiga_500 wrote: post #256

Earlier quoted context omitted.

But it shouldn't require a full compilation. The ultimate result, given the slow compile times of c++, is that you cannot know in your editor if your code is correct.

The IDEs I have used, or IDE-ified editors, run compilation ("indexing", or whatever) in the background to make this work.

This is problematic on large code bases. Huge mistakes were made on C++ design.

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

#323

Post by myrrlyn »

ken wrote: post #290

Should I learn Verilog to understand “how the computer works”?

No; you should learn Verilog to build a computer. It's a common aspect of Computer Engineering curricula, very educational, and ultimately … not all that useful for most software work, even when doing direct hardware interface.

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

#324

Post by myrrlyn »

sys_64738 wrote: post #306
myrrlyn wrote: post #236

Earlier quoted context omitted.

Not a word of what you just wrote is true.

I think you know better.

than to write something like "Atomically [C] is the DNA of all other programming languages"? I do, yes

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

#325

Post by adev_ »

shadowgovt wrote: post #183
oconnor663 wrote: post #25

My favorite take on the severity of the UB problem, https://blog.regehr.org/archives/1520 : > Tools like [Valgrind] are exceptionally useful and they have helped us progress from a world where almost every nontrivial C and C++ program executed a continuous stream of UB to a world where quite a few important programs seem to be largely UB-free in their most common configurations and use cases...Be knowledgeable about…

> Be knowledgeable about what’s actually in the C and C++ standards ... turns out to be an extremely tall order; the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format. At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." At which point the imme…

> At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly."

That's a bullshit argument very close to FUD.

You don't need to know the 1400 pages of the C++ standard to use safely a subset of it. Specially with proper tooling to help you.

Do you really think that every web frontend developer knows every W3C/ECMA standard every time they create a website ? Or that they have even an idea of feature the complexity of the Web browser they use. One tips: no they don't.

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

#326

Post by saagarjha »

still_grokking wrote: post #317
saagarjha wrote: post #273

Earlier quoted context omitted.

The IDEs I have used, or IDE-ified editors, run compilation ("indexing", or whatever) in the background to make this work.

Maybe you want to share which IDEs you've been using? It sounds like a wonder if there is one that can handle C++ in a way comparable to, say, IntelliJ for Java, or VSCode for TypeScript. My experience is frankly more that the usual IDEs I know of can't even handle syntax coloring 100% correct when it comes to C++…

Xcode for well-structured (read: Xcode) projects. Sublime Text with clangd for random editing (not an IDE, but it gets good autocompletion and syntax checking from it).

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

#327

Post by saagarjha »

amiga_500 wrote: post #322
saagarjha wrote: post #273

Earlier quoted context omitted.

The IDEs I have used, or IDE-ified editors, run compilation ("indexing", or whatever) in the background to make this work.

This is problematic on large code bases. Huge mistakes were made on C++ design.

How large are we talking about? I've been able to use these tools on codebases such as WebKit and LLVM…

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

#328

Post by aidenn0 »

jstimpfle wrote: post #304
aidenn0 wrote: post #289

Earlier quoted context omitted.

Don't forget arithmetic operations that can detect various corner cases. Writing something like: sum = x + y; if(sum And then hoping the compiler will optimize your if statment to a single overflow CF check is a bit silly.

That would not prevent the overflow from actually happening, which would be technically UB if the sum is a signed type. It is possible to catch overflow in the last instant like this (in the last instant before executing the addition instruction) but the test is more involved. It's a pity that there are no standardized tools (AFAIK) but it's not possible to write a substantial piece of code in this way, anyway. What…

Right, I was assuming x and y were unsigned types at least as large as an integer. Tests for other types are different.

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

#329

Post by lmm »

tspiteri wrote: post #160
lmkg wrote: post #152

Earlier quoted context omitted.

Not a C expert, just reading what I can find online: This page says value is indeterminate, which is either unspecified or a trap, as you say: https://wiki.sei.cmu.edu/confluence/display/c/EXP33-C.+Do+no... But. This part says that reading an indeterminate value is, in fact, undefined behavior (line 11 in the table): https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+...

That says used , not read . And indeterminate , not unspecified . My point was on reading a value, not on acting on the value. I know it looks like nit-picking, and you should just not read uninitialized memory, but I don't think it's consistent with the standard to say that reading uninitialized memory is always UB.

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.

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

#330

Post by lmm »

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

Unspecified values are constant (since they are values), just unspecified. This behaviour is only permitted because reading uninitialised memory is UB; you won't see the same thing if x is an unspecified value.
Post reply on HN