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

Modern C [pdf]

icube-icps.unistra.fr

Post reply on HN
Print view View original

171–180 of 396 posts

Re: Modern C [pdf]

#171

Post by pcwalton »

buserror wrote: post #105
adamnemecek wrote: post #74

Earlier quoted context omitted.

This C apologism is holding the industry back. Software development has changed many times over since C came out and it just isn't a good tool for tackling a lot of the issues that we have today. Just about every software project written in C has some serious bugs. I personally judge a language by how well it lets you to define abstractions. In C's case, it doesn't let you do that very well.

"Just about every software project written has some serious bugs" There, fixed it for you. Seriously, vulnerabilities and bugs are found everywhere not just in C. I've been programming for 35 years, in so many languages I lost count, and every time I've seen the 'let's not use C because it'll lead to bugs' it was to be replaced by another thing that was ALSO leading to bugs, and/or become so bloated it was in itself.…

> Seriously, vulnerabilities and bugs are found everywhere not just in C.

The black-and-white security fallacy again!

The simple fact (and this is a fact, not an opinion) is that the most severe security problems—remote code execution, in particular—are found way way way more in programs written in C and C++ than in other languages.

Re: Modern C [pdf]

#172

Post by pcwalton »

quickben wrote: post #81
adamnemecek wrote: post #74

Earlier quoted context omitted.

This C apologism is holding the industry back. Software development has changed many times over since C came out and it just isn't a good tool for tackling a lot of the issues that we have today. Just about every software project written in C has some serious bugs. I personally judge a language by how well it lets you to define abstractions. In C's case, it doesn't let you do that very well.

Your criticism lacks constructivity. What do you propose we replace C with?

Rust?

Re: Modern C [pdf]

#173

Post by Nadya »

colanderman wrote: post #156

While I like a lot of what's in here, for (size_t i = 9; i is a pretty terrible example to put in the second chapter. I would not let that line pass code review. There is no need or place for cutesy cleverness in C. EDIT: Ugh, just found this too: isset[!!largeA[i]] += 1; Not only is that confusingly cutesy, but largeA[i] is a double . Please DON'T write – or encourage beginners to write! – such smug code! EDIT2: In…

Given the explanatory text - I think this was more of a "test of intuition" accompanied by a "gotcha!"

As someone unfamiliar with C - I initially thought it would go on forever. The explanatory text explained why I was wrong and this can be equally parts "clever code" or a "gotcha!" depending how you view it. With your experience you're seeing it as overly clever code. With mine, I'm seeing it as a "gotcha". I don't think it is supporting writing code like that. :)

>The third for appears like it would go on forever, but actually counts down from 9 to 0. In fact, in the next section we will see that “sizes” in C, that is numbers that have type size_t, are never negative.

Re: Modern C [pdf]

#174

Post by pcwalton »

module0000 wrote: post #121
adamnemecek wrote: post #113

Earlier quoted context omitted.

How detailed is your knowledge of undefined behavior?

We know when undefined behavior will occur(the specs are written very clearly), but not what will happen when it occurs. Our job as competent C programmers is to avoid undefined behavior. C isn't hard(perhaps tedious to do correctly) - it does exactly what you tell it to.

> it does exactly what you tell it to.

This is a tautology.

What do you expect to happen on signed overflow?

Re: Modern C [pdf]

#175

Post by mitchty »

im3w1l wrote: post #35
mitchty wrote: post #29

Earlier quoted context omitted.

Idris can compile to c, it requires no runtime. You're probably thinking of Haskell with its RTS. Idris is closer to ocaml in that regard. I cough may have already tried using idris in a kernel module. (for fun, not for serious)

And how did it go?

It worked surprisingly enough, well enough to make me consider trying out some gpio stuff to play around with.

From there I'll let you know, I'm still learning Idris and dependent types so I'm a fairly boring test case. This was more of a: lets try it and see what goes kaboom test.

Re: Modern C [pdf]

#176

Post by pcwalton »

pawadu wrote: post #98
pjmlp wrote: post #94

Earlier quoted context omitted.

Historical accident. It could have been written in any other language that compiled to native code, if we had more options available.

Well, there are two types of people in this world 1. the type that do something 2. the type that claim they could do it better than the first group (this is by no means limited to programming, it is for example pretty common in politics) So please show me an OS written in Go or Rust or Ruby or Python or Java that people can actually use for day-to-day tasks.

I've been working full time for years on a browser written in Rust. Which category am I in?

Yes, C++ is very entrenched. That is a problem. We should be fixing that.

Re: Modern C [pdf]

#178

Post by y_u_no_rust »

loup-vaillant wrote: post #149
quickben wrote: post #81

Earlier quoted context omitted.

Your criticism lacks constructivity. What do you propose we replace C with?

Whatever doesn't have extremely tight constraints (CPU, memory, embedded…) should probably use garbage collection. Now your language can throw a nice exception (or otherwise cleanly abort the process) before any memory corruption (and subsequent vulnerabilities) can occur. Otherwise, I'd say try something like Rust. And if Rust doesn't make the cut, maybe go write your own C-like dialect, with less undefined behaviou…

lol rust, get real.

Re: Modern C [pdf]

#179

Post by jackhack »

I wish I could like this book, but after reviewing the first chapter I can only imagine the confusion of students. I support very much the idea of breaking the book into levels, but it attempts to cover far too much, far too quickly and I don't believe this book would be useful for those who are not already familiar with the language.

I've been writing C since the late 1980s, moved to mostly C++ by the mid 90s, C# in the 2000s, and now I've come back to C. Most recently built some realtime components and drivers, having to drop back to C77. I mention this as I've taught many colleagues along the way and I'm sensitive to the places where beginners tend to get hung up with problems and I've come to anticipate many of the questions along the way. Let me take a moment to illustrate the base of the problems i see:

"Too much, too fast." The best example is right on page 2: a program which demonstrates a complex printf format string, along with arrays and loops. I can't help but sarcastically ask "Are you sure that is how you want to introduce someone to the language?" A beginner's eyes will glaze over.

Seriously, the way to introduce the language is simple examples. Explain the main is the entry point where all programs begin running, and that main returns it's success or failure to the operating system (or other program that called it). 3 lines of code.

Then add a SIMPLE print, if you wish, or a variable declaration. Int. Float. char. again, it MUST be simple. Introduce loops. Then show how to move some functionality out of main into a subroutine/a new method/new function, how to call that function, and return results. Talk about header files, etc.

From there, dive into the rest of the base language... talk up arrays, memory management, heap/stack, pointers, libraries, exceptions, etc.

But this is only my experience, and I'm sure that it is different for others. Kind regards.

Re: Modern C [pdf]

#180

Post by steveklabnik »

SQLite wrote: post #78
AsyncAwait wrote: post #68

Earlier quoted context omitted.

> Rust has "immutable variables". Seriously? How can an object be both variable and immutable? "Immutable variables" is frequently used, true, but the official term is "immutable bindings".

Reassuring news. Thanks.

To elaborate slightly, there's three components here:

    let x = 5;
    let mut y = 6;
The let statement binds a variable to a value:

  * x and y are the variables
  * 5 and 6 are values
  * let does the binding
You can have an immutable binding, like x, or a mutable binding, like y. But most people turn "a bound variable" into "a variable" (or "an immutable variable") and "a mutably bound variable" into a "mutable variable".
Post reply on HN