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

231–240 of 396 posts

Re: Modern C [pdf]

#231

Post by DonaldFisk »

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.

Those who did something include the developers of Burroughs MCP, who used Algol 60; the developers of MULTICS, who used PL/1; the developers of Symbolics Genera, who used Lisp; and the developers of Oberon, who used the language Oberon.

I go along with historical accident to account for Unix's success, though Richard Gabriel thought it was a case of Worse Is Better trumping The Right Thing.

Re: Modern C [pdf]

#232

Post by xenihn »

jackhack wrote: post #179

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…

Do you have any recommendations for books?

Re: Modern C [pdf]

#233

Post by kruhft »

The best book I had for learning more about C was titled 'Writing Bug Free Code For Windows' from the late '90s early 2000's. It contained a complete object oriented system using simple header tricks and data hiding plus covered all sorts of pre-processor tricks that aren't evident until you really dig into what C can really do. I'm sure it's impossible to find now, but recommended.

Re: Modern C [pdf]

#234

Post by pcwalton »

bluetomcat wrote: post #227
pcwalton wrote: post #166

Earlier quoted context omitted.

In theory, a good fraction of these can be caught. In practice, these issues keep coming up in production again and again and again.

Knowing your tools and compiler switches is key. The reward is that the final production code can be very lean and performant, without any runtime penalties to provide safety. Most people who complain about the dangers of C probably have used it in an unprofessional setting without any additional tooling. It's a bit like saying that all RWD cars are dangerous just because you've once driven a '92 BMW, disregarding an…

> Most people who complain about the dangers of C probably have used it in an unprofessional setting without any additional tooling. It's a bit like saying that all RWD cars are dangerous just because you've once driven a '92 BMW, disregarding any technological advancements since.

Actually, most of the people I know who think C is a problem that needs fixing are longtime professional compiler developers and people who work on security critical codebases. In fact, I don't know any compiler engineers who don't have serious reservations about C and C++. Those people know more about tooling and instrumentation than virtually anybody. It's precisely that knowledge that leads one rapidly to the conclusion that there are serious flaws in C for secure software that can't just be papered over with tooling.

It's usually C++ enthusiasts who are the ones trying (unsuccessfully, IMO) to argue that undefined behavior isn't a problem in practice.

Re: Modern C [pdf]

#235

Post by kruhft »

PDoyle wrote: post #44
mixedCase wrote: post #42

Earlier quoted context omitted.

>The omission of assert() makes Go a non-starter. A small syntactic sugar you can trivially implement yourself makes Go a non-starter? Go doesn't include assert in the language because you're supposed to do better than assert. Assert easily allows lazy programmers to let their programs freely crash without properly handling error conditions. Go prevents you from compiling with unused variables, and that combined with…

> Assert easily allows lazy programmers to let their programs freely crash without properly handling error conditions. This is what he meant by misuse. Properly-used assertions are meant to document and check conditions that were thought to be impossible by the developer. Not just unlikely, or illegal, but impossible. If a condition is possible, and you check it with assert, that's a bug.

The biggest problem I've seen with assert[1] is putting functioning code inside one and then not knowing why your code no longer works with NDEBUG.

[1] http://en.cppreference.com/w/c/error/assert

Re: Modern C [pdf]

#236

Post by paulmd »

pcwalton wrote: post #171
buserror wrote: post #105

Earlier quoted context omitted.

"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.

I strongly agree with your point in general, memory safety is a major problem with C/C++ to an extent that is not found in other languages. Even worse, these often become problems long after they are written when the compiler gets "smarter" and does a trick with your code. Call it "code rot" or whatever you want, but it happens a lot more and a lot faster on C/C++ than other languages.

However, the nature of where C/C++ code is used does lend itself to severe problems. When you have a JVM vulnerability, you shouldn't be able to get any farther than a regular user with only sandbox privileges. When you have a kernel vulnerability, by definition you have the keys to the kingdom.

Of course there are always holes that can be used to escalate, but that also comes back to the problems of having a primarily C/C++ ecosystem...

Re: Modern C [pdf]

#237

Post by paulmd »

yekim wrote: post #225
chrisd1100 wrote: post #114

I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…

Hear, hear! Unfortunately, C does get a lot of hate on HN. I suspect it has to do with this site's demographics. Many (not all) of the HN clan seem to be oriented towards / mostly familiar with web based technologies. I suspect that for many who have tried, going from a web dev environment to a C oriented dev environment feels like a robust shock to the system. I'd also be willing to bet that there's an age bias at p…

It's not just that HN does a lot of webdev. It's that even in its element as a "systems language" it's virtually impossible to write 100% safe C/C++ code and guarantee that it will remain safe into the future, even for experts who are making every effort to do it right. There are just too many gotchas with "undefined behavior" and too many clever compilers out there waiting for you to make a mistake.

One only needs to look at something like the OpenSSL library to see the problem. You really need to hammer the hell out of C code with something like AFL to get at a reasonable majority of bugs - and you could hammer out every last bug one day and then the next day a compiler starts optimizing away your safety checks. This isn't a theoretical problem, this actually happens. Code rot is a very real problem in C++, to a far more massive extent than any other language.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://www.kb.cert.org/vuls/id/162289

Personal opinion here, but with few exceptions C/C++ are inappropriate languages for starting new development at this point. I realize the tooling is not there yet but I would rather see something like Rust used in almost all performance-sensitive applications where C/C++ are currently used. Unless you can guarantee that you are operating in a trusted environment and will only ever operate on trusted data, C/C++ is just not the right language for the job.

Yes, it's fast, but at what cost? I would gladly give up a massive fraction of my performance for better security and portability - and that's why I program Java. Not that Java is perfect either, but at least I can be certain that the sands aren't shifting out underneath my programs.

I would actually say that porting the Linux kernel to Rust would be very high on my wish-list at this point. I am well aware of just how enormous that task would be and I might as well wish for a pony too, but it gives me heartburn to think of just how much C code is sitting there operating in the most untrusted of environments on the most untrusted of data. I have every faith in the kernel guys to do it right, but the reality is there is a lot of attack surface there and it's really easy to make a mistake in C/C++. It may not even be a mistake today, only when the compiler gets a little more clever.

Re: Modern C [pdf]

#238

Post by ape4 »

72deluxe wrote: post #226
ape4 wrote: post #213

Earlier quoted context omitted.

This looks fine to me. I wonder if C/C++ could be improved by introducing a new keyword `bail` which is the same as `goto` but is only allowed to jump to the bottom of the function. That way, codebases can outlaw `goto` but keep `bail`.

Are you looking for "return"? With C++ you can ensure that you have your destructors do the tidy up, e.g. a messy example struct cleaner { cleaner(string *toCleanup) : m_x(toCleanup) { } ~cleaner() { delete m_x; m_x = nullptr; } };

Yup, C++ has autocleanup. Of course if you are using fopen() instead something more modern you'll need to fclose(). Adding a new keywords to C is a long shot. Perhaps compilers could detect non-cleanup use of goto and give it a warning.

Re: Modern C [pdf]

#239

Post by sidlls »

junke wrote: post #216
chrisd1100 wrote: post #202

Earlier quoted context omitted.

But don't the security vulnerabilities come from poorly implemented code? These vulnerabilities are not inherent to C.

Vulnerabilities like buffer overflow do not happen in languages with a string type. Humans are responsible if something bad happens, but without a safety net, the outcome is worse.

Your first statement is pretty false, even in Rust (for example). Unless you mean something else by "buffer overflow" than I'm accustomed to.

Re: Modern C [pdf]

#240

Post by pieterr »

xenihn wrote: post #232
jackhack wrote: post #179

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…

Do you have any recommendations for books?

K&R: https://www.amazon.com/gp/aw/d/0131103628/
Post reply on HN