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

Everything I wish I knew when learning C

tmewett.com

Post reply on HN
Print view View original

151–160 of 401 posts

Re: Everything I wish I knew when learning C

#151

Post by titzer »

LegionMammal978 wrote: post #143
andrewmcwatters wrote: post #140

Earlier quoted context omitted.

Personally, I've found that some of the optimizations cause undefined behavior, which is so much worse. You can write perfectly good, strict C that does not cause undefined behavior, then one pass of optimization and another together can CAUSE undefined behavior. When I learned this, if it was and is correct, I felt that one could be betrayed by the compiler.

Optimizations themselves (except for perhaps -ffast-math) can't cause undefined behavior: the undefined behavior was already there. They can just change the program from behaving expectedly to behaving unexpectedly. The problem is that so many snippets, which have historically been obvious or even idiomatic, contain UB that has almost never resulted in unexpected behavior. Modern optimizing compilers have only been c…

There have been more than a few compiler bugs that have introduced UB and then that was subsequently optimized, leading to very incorrect program behavior.

Re: Everything I wish I knew when learning C

#152

Post by skitter »

andrewmcwatters wrote: post #140
titzer wrote: post #125

Earlier quoted context omitted.

> how insidious undefined behavior is. Indeed. UB in C doesn't mean "and then the program goes off the rails", it means that the entire program execution was meaningless, and no part of the toolchain is obligated to give any guarantees whatsoever if the program is ever executed , from the very first instruction. A UB-having program could time-travel back to the start of the universe, delete it, and replace the entire…

Personally, I've found that some of the optimizations cause undefined behavior, which is so much worse. You can write perfectly good, strict C that does not cause undefined behavior, then one pass of optimization and another together can CAUSE undefined behavior. When I learned this, if it was and is correct, I felt that one could be betrayed by the compiler.

Any optimization that causes undefined behavior is bugged – please report them to your compiler's developers.

Re: Everything I wish I knew when learning C

#153

Post by 0xbadcafebee »

More Good projects to learn from:

  - Busybox (https://github.com/mirror/busybox)
  - uClibc (https://git.uclibc.org/uClibc/tree/)
  - musl (https://git.musl-libc.org/cgit/musl/tree/)
  - misc GNU tools (https://git.savannah.gnu.org/cgit/grep.git/tree/, https://git.savannah.gnu.org/cgit/findutils.git/tree/, etc)
The first two are oriented towards embedded development, which I find leads to the simplest, most portable code. Those devs are absolute wizards.

Re: Everything I wish I knew when learning C

#154

Post by hellfish »

lebuffon wrote: post #83

" ... is often called the stack." " integers are cursed" These statements and a few others made me uncomfortable. They imply, to me, that the author has too little knowledge of computer internals to be programming in C. C does a wonderful job of looking like a high level language but it was designed to do low level stuff. There is an implicit assumption, to my mind, that the user has a deeper understanding of what is…

> " ... is often called the stack."

What's wrong about the stack part? It seemed a little odd (and unnecessarily abstract) that the author said "automatic storage" instead of just stack

is there a situation where there's automatic storage but no stack?

Re: Everything I wish I knew when learning C

#155

Post by Existenceblinks »

Koshkin wrote: post #112
alexandreyc wrote: post #110

After more than a decade without writing any C code, I'm currently reading "C Programming: A modern Approach" by K. N. King ( http://www.knking.com/books/c2/ ) and I found it very good. I think it's a better modern alternative to the K&R.

832 pages is not a "better alternative."

Plus, it's 2008. 14 years is enough for lots of thought to have a revisit with revise. If there's a very good C book in 2023 I would buy it.

Edit: No, change my mind. I'd go for Zig book instead!

Re: Everything I wish I knew when learning C

#156

Post by retrac »

DSMan195276 wrote: post #72

I like it, but the array details are a little bit off. An actual array does have a known size, that's why when given a real array `sizeof` can give the size of the array itself rather than the size of a pointer. There's no particular reason why C doesn't allow you to assign one array to another of the same length, it's largely just an arbitrary restriction. As you noted, it already has to be able to do this when assi…

> it's largely just an arbitrary restriction

Kind of. But the restriction is in keeping with the C philosophy of no hidden implementation magic. C has the same restriction on structs. That's the same question; an array of bytes of known size to the compiler it could easily abstract away. But assignment is always a very cheap operation in C. If we allow assigning to represent memcpy() that property is no longer true.

Same reason why Rust requires you to .clone() so much. It could do many of the explicit copies transparently, but you might accidentally pass around a 4 terabyte array by value and not notice.

Re: Everything I wish I knew when learning C

#157

Post by joosters »

titzer wrote: post #151
LegionMammal978 wrote: post #143

Earlier quoted context omitted.

Optimizations themselves (except for perhaps -ffast-math) can't cause undefined behavior: the undefined behavior was already there. They can just change the program from behaving expectedly to behaving unexpectedly. The problem is that so many snippets, which have historically been obvious or even idiomatic, contain UB that has almost never resulted in unexpected behavior. Modern optimizing compilers have only been c…

There have been more than a few compiler bugs that have introduced UB and then that was subsequently optimized, leading to very incorrect program behavior.

A compiler bug is a compiler bug, UB or not. You might as well just say "There have been more than a few compiler bugs, leading to very incorrect program behavior."

Re: Everything I wish I knew when learning C

#158

Post by kllrnohj »

hzhou321 wrote: post #150
titzer wrote: post #125

Earlier quoted context omitted.

> how insidious undefined behavior is. Indeed. UB in C doesn't mean "and then the program goes off the rails", it means that the entire program execution was meaningless, and no part of the toolchain is obligated to give any guarantees whatsoever if the program is ever executed , from the very first instruction. A UB-having program could time-travel back to the start of the universe, delete it, and replace the entire…

> Indeed. UB in C doesn't mean "and then the program goes off the rails", it means that the entire program execution was meaningless, and no part of the toolchain is obligated to give any guarantees whatsoever if the program is ever executed, from the very first instruction. This is the greatest sin modern compiler folks committed to abuse C. C as the language never says the compiler can change the code arbitrarily d…

> It is definitely not, e.g., an assertion on the operand because UB can't happen.

C specification says a program is ill-formed if any UB happens. So yes, the spec does say that compilers are allowed to assume UB doesn't happen. After all, a program with UB is ill-formed and therefore shouldn't exist!

I think you're conflating "unspecified behavior" and "undefined behavior" - the two have different meanings in the spec.

Re: Everything I wish I knew when learning C

#159

Post by fwip »

pif wrote: post #54
torstenvl wrote: post #19

Earlier quoted context omitted.

I like that a lot! However, it makes things like int *x = &a; a bit more confusing/inconsistent.

Not at all! a is int; &a is pointer to int; x is pointer to int; *x in again int.

Gotcha, so it's kind of like:

    int (*(x = &(a)));
    i    i p   p i   // i means int, p means pointer

Re: Everything I wish I knew when learning C

#160

Post by nayuki »

titzer wrote: post #151
LegionMammal978 wrote: post #143

Earlier quoted context omitted.

Optimizations themselves (except for perhaps -ffast-math) can't cause undefined behavior: the undefined behavior was already there. They can just change the program from behaving expectedly to behaving unexpectedly. The problem is that so many snippets, which have historically been obvious or even idiomatic, contain UB that has almost never resulted in unexpected behavior. Modern optimizing compilers have only been c…

There have been more than a few compiler bugs that have introduced UB and then that was subsequently optimized, leading to very incorrect program behavior.

A compiler bug cannot introduce UB by definition. UB is a contract between the coder and the C language standard. UB is solely determined by looking at your code, the standard, and the input data; it is independent of the compiler. If the compiler converts UB-free code into misbehavior, then that's a compiler bug / miscompilation, not an introduction of UB.
Post reply on HN