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

Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

cl.cam.ac.uk

Post reply on HN
Print view View original

181–190 of 253 posts

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#181

Post by clarry »

WalterBright wrote: post #168
ktRolster wrote: post #161

Earlier quoted context omitted.

OpenBSD takes a fairly minimalist approach, which is vaguely described here: http://www.freebsdforums.org/forums/showthread.php?threadid=... They basically replace the unsafe functions with things that are easier to use. Their idea is that it isn't the format of the C-string that causes security issues (null-terminated string), it's the poorly defined functions (with weird corner cases that are hard to get right). It…

I used snprintf(), too, but it is only a minor improvement. Problematic in C is something as simple as concatenating strings: Mystring s,t; t = "hello"; t = cat(s,s); t = cat(s,s,s); t = cat("hello",s); t = cat(s,"world"); t = cat("hello","world"); Even such a simple use case is fraught with major problems: 1. who allocates needed memory? 2. who free's it? 3. can the compiler constant fold cat("hello","world") ? Does…

> Even such a simple use case is fraught with major problems: > > 1. who allocates needed memory? > > 2. who free's it?

That's also a major feature. It allows people to write systems that are resilient in the face of tight memory limitations. It's not cool when a language forces string operations to allocate & duplicate memory willy-nilly.

> 3. can the compiler constant fold cat("hello","world") ? Does the result wind up allocating memory anyway?

I fail to see how that's a major problem. Why are you concatenating string literals? How common is that?

> 4. what about the lack of function overloading to handle the permutations?

I consider lack of overloading to be a feature. Overloading is one of the things that are way too easily abused, and it makes code auditing harder than it needs to be. Please just type out the different function names so I can see exactly what is going to be called when I read the code. Or use the sprintf family of variadic functions.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#182

Post by mike_hearn »

ChuckMcM wrote: post #48
jasode wrote: post #5

This is a long paper and the author has 2 main claims: 1) C Language popularity is more to do with cognitive ease of memory addresses as a conceptual model for inspection and change. Author claims memory address mental model overshadows runtime performance . 2) switching to "safe" languages like Java/C#/Rust is not necessary. With no changes/violations to existing C Language specification, a new/different implementat…

Excellent, I think the author would do well to re-frame the question as you have. If nothing else to put it more clearly into the space of provable compilation. When I transferred into the "Oak" group that later became the "Java" organization, the team I was on was looking at whether or not you could write an OS in Java sort of in spite of its safety rules. This sort of concept has been revisited by Rust with its saf…

It's a very intriguing idea and you may be pleased to know that such research lines are still being explored:

http://ssw.jku.at/General/Staff/ManuelRigger/ManLang17.pdf

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#183

Post by mike_hearn »

ktRolster wrote: post #50
jasode wrote: post #5

This is a long paper and the author has 2 main claims: 1) C Language popularity is more to do with cognitive ease of memory addresses as a conceptual model for inspection and change. Author claims memory address mental model overshadows runtime performance . 2) switching to "safe" languages like Java/C#/Rust is not necessary. With no changes/violations to existing C Language specification, a new/different implementat…

It's not just the mental ease, it's also the physical typing ease (and in some cases, the possibility). For example, he points out that to connect C to existing parts of the system (which is the OS and OS level tools), all you have to do is call the functions. If you want to call a C library from a Java program, it's a lot more work. Furthermore, C has the capability of understanding Java structures (although it's aw…

That's not inherent to the Java language. You can implement garbage collectors and kernels in Java if you extend the JIT compiler:

http://jnode.org/

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#184

Post by mike_hearn »

clarry wrote: post #181
WalterBright wrote: post #168

Earlier quoted context omitted.

I used snprintf(), too, but it is only a minor improvement. Problematic in C is something as simple as concatenating strings: Mystring s,t; t = "hello"; t = cat(s,s); t = cat(s,s,s); t = cat("hello",s); t = cat(s,"world"); t = cat("hello","world"); Even such a simple use case is fraught with major problems: 1. who allocates needed memory? 2. who free's it? 3. can the compiler constant fold cat("hello","world") ? Does…

> Even such a simple use case is fraught with major problems: > > 1. who allocates needed memory? > > 2. who free's it? That's also a major feature. It allows people to write systems that are resilient in the face of tight memory limitations. It's not cool when a language forces string operations to allocate & duplicate memory willy-nilly. > 3. can the compiler constant fold cat("hello","world") ? Does the result win…

It's the opposite. I've seen lots of code written in C that pretends to be out of memory safe. I've never once seen such a program that actually is out of memory safe. Invariably the codepaths triggered by malloc returning null are never exercised.

With a GC and exceptions you can theoretically be quite resistant to OOM conditions, not that anyone really cares.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#185

Post by mike_hearn »

bsder wrote: post #113
jasode wrote: post #5

This is a long paper and the author has 2 main claims: 1) C Language popularity is more to do with cognitive ease of memory addresses as a conceptual model for inspection and change. Author claims memory address mental model overshadows runtime performance . 2) switching to "safe" languages like Java/C#/Rust is not necessary. With no changes/violations to existing C Language specification, a new/different implementat…

C's popularity is due to the fact that it is predictable within certain bounds (single thread or limited concurrency). No GC pauses, no weird runtime crashes due to a strange constructor, no gigantic exception chains, etc. The only languages in the TIOBE index that can even try to make that claim are: C at #2, C++(if you subset it) at #3, Objective-C/Swift(#18/#11), Assembly at #14, Ada at #29, and maybe FORTRAN(#35)…

The idea that C is predictable is in my view a sign of someone who hasn't got to know C really well.

The trends around undefined behaviour will hopefully put a bullet in the head of this idea for good. It's extremely hard to look at C and reason about what an optimising compiler will turn it into.

Malloc is not more predictable than a GC pause. Both malloc and free can take unpredictable amounts of time. If anything it's less predictable because modern GCs at least have pause time targets, but mallocs never do. You just don't notice it because people don't tend to measure malloc latency. In turn that's because malloc pauses only affect memory allocation operations, they don't stop every thread, which is a benefit it's true, but it's not about predictability and more about UI latency.

C not having exceptions doesn't make it more predictable. It just means that if something goes wrong you get a useless and probably corrupted core dump. The number of times I've been able to fix a bug in a piece of managed code given only a stack trace from the end user is huge. The number of times I've been able to fix a bug given "Segmentation fault" with no other info is zero.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#186

Post by JdeBP »

WalterBright wrote: post #168
ktRolster wrote: post #161

Earlier quoted context omitted.

OpenBSD takes a fairly minimalist approach, which is vaguely described here: http://www.freebsdforums.org/forums/showthread.php?threadid=... They basically replace the unsafe functions with things that are easier to use. Their idea is that it isn't the format of the C-string that causes security issues (null-terminated string), it's the poorly defined functions (with weird corner cases that are hard to get right). It…

I used snprintf(), too, but it is only a minor improvement. Problematic in C is something as simple as concatenating strings: Mystring s,t; t = "hello"; t = cat(s,s); t = cat(s,s,s); t = cat("hello",s); t = cat(s,"world"); t = cat("hello","world"); Even such a simple use case is fraught with major problems: 1. who allocates needed memory? 2. who free's it? 3. can the compiler constant fold cat("hello","world") ? Does…

Here's roughly what that would look like using Bernstein's C string library (which was not only used in qmail).

    #include "stralloc.h"
    ...
    static stralloc s, t;
    ...
    if (!stralloc_ready(&s, 0)) die_nomem();

    if (!stralloc_copys(&t, "hello")) die_nomem();

    if (!stralloc_copy(&t, &s)) die_nomem();
    if (!stralloc_cat(&t, &s)) die_nomem();

    if (!stralloc_copy(&t, &s)) die_nomem();
    if (!stralloc_cat(&t, &s)) die_nomem();
    if (!stralloc_cat(&t, &s)) die_nomem();

    if (!stralloc_copys(&t, "hello")) die_nomem();
    if (!stralloc_cat(&t, &s)) die_nomem();

    if (!stralloc_copy(&t, &s)) die_nomem();
    if (!stralloc_cats(&t, "hello")) die_nomem();

    if (!stralloc_copys(&t, "hello")) die_nomem();
    if (!stralloc_cats(&t, "world")) die_nomem();

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#187

Post by [deleted] »

flukus wrote: post #132
burntsushi wrote: post #102

Earlier quoted context omitted.

> As a user, I don't care what makes your life easier as a developer You should. The easier my life is, the faster I can fix bugs and put out new releases.

I'm dealing with the result of this attitude on my phone right now. The end result is I can't even install your app because I'm out of space on my phone. I'm out of space because every other app maker favored developer productivity over being conservative with users resources. It's a tragedy of the commons.

[deleted]

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#188

Post by burntsushi »

flukus wrote: post #132
burntsushi wrote: post #102

Earlier quoted context omitted.

> As a user, I don't care what makes your life easier as a developer You should. The easier my life is, the faster I can fix bugs and put out new releases.

I'm dealing with the result of this attitude on my phone right now. The end result is I can't even install your app because I'm out of space on my phone. I'm out of space because every other app maker favored developer productivity over being conservative with users resources. It's a tragedy of the commons.

Seems like you are shifting the goal posts. If I'm building something to run on resource constrained devices, then it makes sense to value use of resources more highly! But otherwise, most of your comments just seem to repeat the same old dynamic vs static linking debate that had been hashed out already for decades. There is no one right answer. Trade offs abound.

People who expect a stable ABI from Rust such that normal Rust libraries can be dynamically linked like you would C libraries would do well to adjust their expectations. It isn't happening any time soon.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#189

Post by nly »

pcwalton wrote: post #78
nly wrote: post #57

Earlier quoted context omitted.

> I could equally well say that there's no "sane" way to implement a safe owning pointer in C++ unique_ptr + std::move gives you that semantically. Sure it won't stop you from dereferencing a null pointer but, in all the years i've been writing C++, finding and fixing null pointer dereferences wouldn't rank very high on my list of things to worry about. They always kill your program and are easy to spot in an IDE or…

Unique pointers provide no protection against use after free, because you can take a reference to their contents and that reference can become dangling. Because the destructor of a unique pointer is invoked automatically per the language rules, as opposed to in C where an explicit call to free is required, this makes C++ more prone to UAF than C.

> Unique pointers provide no protection against use after free, because you can take a reference to their contents and that reference can become dangling.

Yes, it's possible, however references should only ever have local scope so, unless you're dealing with threads or asynchrony it's hard to write sane code where this happens, and if you have those things, and you're passing refs or ptrs, then I don't have to tell you that things are bad.

> as opposed to in C where an explicit call to free is required, this makes C++ more prone to UAF than C.

I don't see this. C++ destructors run after the last line of your code block, if something uses a destructed object then it can only be because you passed a pointer or reference to it to something else that wasn't yet destroyed.

Mentioning free() just implies that you're willing to accept resource leaks to avoid UAF bugs, which is nuts because UAFs can be a lot easier to debug.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#190

Post by dig1 »

pcwalton wrote: post #27
dig1 wrote: post #22

Earlier quoted context omitted.

> Switching to a new compiler is a very high burden for a lot of projects ... By contrast, switching to a new language ... is also a very high burden, but the benefits are larger I guess switching to a new compiler (or newer version of the same vendor) is much less burden than switching to the new language. Don't forget that all "new safe languages" are simply new. Why people like C is familiarity: known practices an…

> I guess switching to a new compiler (or newer version of the same vendor) is much less burden than switching to the new language. If that were true, then Linux distros wouldn't still be using GCC. Switching to a new compiler (like clang) is a huge burden. Both switching compilers and switching languages are enormously expensive, to be sure. But I think people (especially people in academia) consistently underestima…

> If that were true, then Linux distros wouldn't still be using GCC.

Simply because there is no better alternative (clang doesn't bring anything new). However, distros switched to egcs fork when gcc wasn't up to date.

> New programmers, by and large, don't even know C anymore.

New programmers are interested in web, just like they aren't interested in desktop GUI development. Should I say that desktop is dead? I don't see we are booting usable machines in browsers yet.

> The problems with C haven't been so much "ironed out" as ignored since C99.

I think you need to hang more with embedded/kernel/C devs more and get insight into their mindset. They aren't interested in new stuff as much as in language stability.

> You bring up Java as though it were a failure! Java has in fact been beating C++ in total usage for years.

You read it wrong - I haven't said Java failed, but introduced new stuff to cope with. Java should thank it's popularity to huge ecosystem and library, Sun's aggressive marketing, jvm and extreme language stability.

> If I could point to one thing that was responsible for kickstarting the slow decline of C++ that has continued to this day, Java would be it.

Did I mention C++ here?

Post reply on HN