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

331–340 of 387 posts

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

#331

Post by overgard »

dooglius wrote: post #137
vardump wrote: post #127

Earlier quoted context omitted.

Pseudo-code: a = 10; b = 20; c = b + 30; bar = a + b; x = 1; y = 2; z = y + 3; foo = x + y; ... in order to remove dependency stalls might be executed as: b = 20; y = 2; a = 10; x = 1; c = b + 30; z = y + 3; bar = a + b; foo = x + y; This would still be true, even if 'x' and 'a', 'y' and 'b' etc. variables (well, registers) had same name. In that case CPU would just make up new "variables" as required and do the same…

Okay, you're talking about OoO execution here, and you're right that this can be hard to reason about (in terms of stalls/latencies), however that's orthogonal to microcode translation.

I don't understand how you can acknowledge the cpu is literally rewriting your code on the fly by changing the order of operations and making things massively parallel and rewriting things in a proprietary language, while holding the belief that "microcode is really not that different from assembly". At least you can inspect what a C compiler emits to assembly.

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

#332

Post by nkurz »

NobodyNada wrote: post #274
hexane360 wrote: post #136

Earlier quoted context omitted.

Even casting 0x12345678 to int* is undefined behavior

It's implementation-defined, not undefined (see [0]). That means the behavior is well-defined by your implementation rather than by the C standard, so the code may work on one implementation but not on others. [0]: https://stackoverflow.com/q/2397984/3476191

What makes you sure of this? I'm reasonably familiar with modern C, but I don't feel confident of the answer here. A search of Stackoverflow doesn't bring up anything that seems authoritative for C. The most relevant quotation I can find is in the Rational for C99, where Section 6.3.2.3 has:

Implicit in the Standard is the notion of invalid pointers. In discussing pointers, the Standard typically refers to “a pointer to an object” or “a pointer to a function” or “a null pointer.” A special case in address arithmetic allows for a pointer to just past the end of an array. Any other pointer is invalid.

An invalid pointer might be created in several ways. An arbitrary value can be assigned (via a cast) to a pointer variable. (This could even create a valid pointer, depending on the value.) A pointer to an object becomes invalid if the memory containing the object is deallocated or moved by realloc. Pointer arithmetic can produce pointers outside the range of an array.

Regardless how an invalid pointer is created, any use of it yields undefined behavior. Even assignment, comparison with a null pointer constant, or comparison with itself, might on some systems result in an exception.

I'm not a language lawyer, but I suspect this means that even initialization to the wrong literal might well be undefined behavior. What makes you confident that it's not, and instead is merely implementation defined?

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

#334

Post by pizlonator »

saagarjha wrote: post #264
pizlonator wrote: post #173

Earlier quoted context omitted.

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 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 profound effects (stores have super weak may alias rules) and calls clobber everything. Put those things together and it’s unusual that a programmer expecting proper structured assembly behavior from their illegally (according to spec) computed pointer would get anything other than correct structured assembly behavior. Like, except for obvious cases, the C compiler has no clue what a pointer points at. That’s great news for professional programmers who don’t have time for bullshit about abstract machines and just need to write structured assembly. You can do it because either way C has semantics that are not very amenable to analysis of the state of the heap.

Partly it’s also because of the optimizations went further, they would break too much code. So it’s just not going to happen.

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

#335

Post by amiga_500 »

saagarjha wrote: post #327
amiga_500 wrote: post #322

Earlier quoted context omitted.

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…

LLVM has 2.5 million lines of code, but I think it also depends upon the number of templated methods etc, not just LOC.

I'm surprised you haven't seen this point made many times. It would be a full-time job on the internet asking people why they have code completion issues with C++ IDEs.

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

#336

Post by thesuperbigfrog »

myrrlyn wrote: post #321
yjftsjthsd-h wrote: post #283

Earlier quoted context omitted.

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/

What hardware does it run on?

I looked through the documentation and cannot find what hardware it runs on and how to set it up. The Getting Started for real hardware returns a 404 page: https://doc.redox-os.org/book/real_hardware.html

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

#337

Post by strategarius »

Is someone thinking so? Really? THIS is how computer works: https://software.intel.com/en-us/articles/intel-sdm

I remember we started our University course of low-level programming from writing in machine codes. No jokes, took binary representation of assembly instructions from that manual and wrote in HEX editor. Then we disassembled simple C applications, understanding unfolding our high-level instructions into x86 assembly. Passing parameters through registres, through stack, two models of stack restoration (yeah, cdecl and stdcall, that moment I realized what does it mean), and other stuff you won't be ever bothered to think about writing in C/C++. And only after that started writing in actual Assembly. THIS is knowledge how computer works. If you know only C, you know nothing.

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

#338

Post by ncmncm »

tspiteri wrote: post #295
ncmncm wrote: post #268

Earlier quoted context omitted.

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

Only if there was UB, and the point is that there probably isn't. (I'm not really knowledgeable on the C standard, so I might have misinterpreted something.)

Making an "if" statement depend on the value of the uninitialized memory is an example of what is meant by using the value, and thus UB.

In the compiler discovers UB, the Standard places no requirements of any kind on the program or compiler. It is free to launch missiles, or (more likely) assume this code cannot be reached, and omit it from the program, along with any code that reaches it unconditionally, and any check that would send control that way. Such elision is the basis for many important optimizations.

Implementations are free to define things left undefined by Standards. For example, "#include " is UB by the ISO Standard, but defined by Posix, which implementations also adhere to.

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

#339

Post by icedchai »

nkurz wrote: post #332
NobodyNada wrote: post #274

Earlier quoted context omitted.

It's implementation-defined, not undefined (see [0]). That means the behavior is well-defined by your implementation rather than by the C standard, so the code may work on one implementation but not on others. [0]: https://stackoverflow.com/q/2397984/3476191

What makes you sure of this? I'm reasonably familiar with modern C, but I don't feel confident of the answer here. A search of Stackoverflow doesn't bring up anything that seems authoritative for C. The most relevant quotation I can find is in the Rational for C99, where Section 6.3.2.3 has: Implicit in the Standard is the notion of invalid pointers. In discussing pointers, the Standard typically refers to “a pointer…

I found this: https://stackoverflow.com/questions/51083356/does-the-c-stan...

What if it's not an "invalid pointer", but a pointer to a memory-mapped IO address, ROM, etc? I grew up learning C on 16-bit machines in the early 90's. Hard coded pointer values were very, very common.

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

#340

Post by saagarjha »

amiga_500 wrote: post #335
saagarjha wrote: post #327

Earlier quoted context omitted.

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

LLVM has 2.5 million lines of code, but I think it also depends upon the number of templated methods etc, not just LOC. I'm surprised you haven't seen this point made many times. It would be a full-time job on the internet asking people why they have code completion issues with C++ IDEs.

No, I know what you're talking about; this is an issue in general if you'd not using tooling that's aware of the ins and outs of C++. The point is that the IDEs I have used essentially run the compiler on the file, so they can actually understand what the templates are doing and get through them.
Post reply on HN