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

221–230 of 253 posts

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

#221

Post by rurban »

ktRolster wrote: post #125
WalterBright wrote: post #109

Earlier quoted context omitted.

> mental ease I'm a long time C programmer, and I was struck by how clumsy and error-prone any manipulation of C strings turns into. It's really hard to look at a mass of strlen/strcpy/memcpy/etc. and see just what is happening. Contrast that with, say, BASIC or Javascript, where string manipulation is easy, natural, and bug-free. I'm going to disagree about the mental ease of programming in C, and a large part of th…

That particular problem (strlen/strcpy/memcpy) comes from the problems of the standard library string functions. It can be solved by creating your own string library. Then string manipulation is easy.

This problem was actually solved, but almost nobody uses it. Safe variants of most of those string, memory, io, wchar, stdlib and misc functions are defined in the C11 standard Annex K (finally after 9 years), but nobody is using it, and rather propose to keep using known unsafe variants like the truncating versions with an n. Like snprintf and not the safe variant sprintf_s. glibc, bsd, darwin, musl, newlib: nobody cares to implement the safe bounds checking variants. They solely rely on the compile time size checks, which fail to check any dynamic boundaries. Only Microsoft, Android, Cisco and Embarcadero implement the safe libc functions. I recently took over Cisco's safelibc (MIT licensed) and extended it to more platforms, all C11 api's, and an improved testsuite. And boy was I surprised to find so many missing API's, upstream libc bugs and wrong API's everywhere. Flawless were only musl and the BSD's. But musl is lacking with it's errno and of course zero C11. Only ReactOS has a proper testsuite for their libc. Glibc is somewhat ok, but I still find crashes daily.

https://github.com/rurban/safeclib

So why is nobody else implementing C11? I'll write a blog post when I finished my C11 efforts. Maybe at least FreeBSD will take it then.

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

#222

Post by nly »

pcwalton wrote: post #217
nly wrote: post #213

Earlier quoted context omitted.

If you're calling a method on the object referred to by a unique_ptr, then you won't have a use-after-free because the thing will exist. The only way it wouldn't exist would be if you typed "delete myuniquePtr.get()", which would be dumb. It could be a null unique_ptr of course, but I don't see how this is anything worse than a denial-of-service.

No, you could get a reference to the container of the object and indirectly delete it. For example, if the unique pointer were part of a global std::vector, clearing the vector would invalidate the this pointer. Keep in mind that you are at this point arguing against the existence of actual zero-days that have occurred in Firefox (and lots of other software). This is not a theoretical concern.

This goes back to what I said about using pointers as implementation details. If you put unique_ptrs in to a _global_ then you're doing something stupid already. Just think about it. Why does something that can only be pointed to from one place need to visible globally in the first place?

My point is all Rust does is force you stop and think, and while C++ lets you do dumb shit, it's hardly fair to blame the language when almost-safe C++ is actually cleaner and easier to read and write than dumb C++.

Build your own handle types with well-defined ownership semantics, use explicit move() sparingly, pass objects by value, use references, utilize the stack and temporaries. Only put pointers inside the guts of classes and your data structure implementations. These techniques go quite far.

And Firefox as an appeal to authority is hardly compelling. As another, I've seen bug fixes in Chromium where the original code quality is so poor it was hard to believe it came out of Google. Of course, since then i've learned most C++ out of Google is total crap.

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

#223

Post by lomnakkus »

ktRolster wrote: post #211
lomnakkus wrote: post #194

Earlier quoted context omitted.

... and end up with silent truncation unless you happen to always remember to use only C library functions with explicit length arguments (and which do not assume NUL-terminated strings). Look, I get that there is a place for C, but string manipulation is absurdly bad and error-prone.

Hi! I can't imagine how you understood what I wrote. I specifically said to not use those C library string functions. I fully admitted that string manipulation is absurdly bad and error-prone, then built on that by showing a way to make it better. Use ktStrcat() instead of strCat(), then you don't have to worry about truncation. Use ktSprintf() instead of snprintf(), then you don't have to worry about truncation. I w…

Yes, I agree. If everyone would just avoid those C stdlib functions everything would be peachy. :)

I was agreeing with you, but just adding caveats. :)

Well, except... some problems surface when interfacing with "things" (libraries, OS'es) written by other people... and there's no escaping those problems, fundamentally. It's C. Of course UTF-8 was invented with the express purpose of being "C-compatible", but... what happens if you have a string with a NUL in it and you pass that to the POSIX (I think?) printf function as an argument for a "%s" format string? Well, it gets truncated. Did you mean for that to happen, or didn't you? Who knows? That's the problem.

Honestly, I'm not trying to win "internet points" or something. It's just that C, as I'm trying to point out, is a bad language for almost everything that's required for a "user-facing" languages these days. Write the thing in C#, Java, O'Caml, Qt[1], or Haskell, or whatever... but please don't think you need to write in a sort of weird approximiation of the old PDP.

[1] Yeah, yeah, not a language, but it's at least an ecosystem that seems to be moderately successful.

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

#224

Post by fulafel »

bsder wrote: post #218
fulafel wrote: post #179

Earlier quoted context omitted.

Isn't this a circular argument: C is popular because no other language on the top popularity chart does . There are many languages with the these properties and better safety, but they aren't popular like C.

Really? I'd love their names. I'm not being snarky here. I'd love to have a nice language alternative to C.

I'm going to link to pjmlp's comment who knows more about these: https://news.ycombinator.com/item?id=14700251#14701140

I was more referring to the historical perspective of how C became popular, many have fallen by the wayside. Though there are certainly current alternatives to C besides those on TIOBE.

Also there are real-time extensions to current GC'd languages like Java.

(Though standard C isn't very predictable timing-wise either, or suited to real-time work)

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

#225

Post by bsder »

fulafel wrote: post #224
bsder wrote: post #218

Earlier quoted context omitted.

Really? I'd love their names. I'm not being snarky here. I'd love to have a nice language alternative to C.

I'm going to link to pjmlp's comment who knows more about these: https://news.ycombinator.com/item?id=14700251#14701140 I was more referring to the historical perspective of how C became popular, many have fallen by the wayside. Though there are certainly current alternatives to C besides those on TIOBE. Also there are real-time extensions to current GC'd languages like Java. (Though standard C isn't very predictable…

And, with the exception of Ada and Pascal, most of those language have been dead for at least 20 years--for various good reasons.

And, please do remember that Apple switched away from Pascal when writing its operating systems in spite of an enormous code base. That's pretty damning--apparently C's "undefined behavior" didn't seem to matter.

So, we're back to: the only alternative to C is Ada.

> Though there are certainly current alternatives to C besides those on TIOBE.

Let me make it easy. Give me a list of languages that have been used to build an operating system in a product in the last 20 years. It doesn't have to be Linux, even a small RTOS counts.

I'll start the list:

C family--C, C++, ObjC/Swift

Forth(?)--probably counts as it runs on pretty bare metal

Ada--not sure anybody has used it to build an OS, but I don't debate that they could

Rust--has a feature set of articles about this

Pascal--the original Lisa and Macintosh OS (probably stretching that 20 year limit a bit).

And?

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

#226

Post by blub »

pcwalton wrote: post #210
blub wrote: post #178

Earlier quoted context omitted.

It's unusual to take references to the contents of a unique pointer. There is one idiom which says that if one has a smart ptr and a function taking a ref, the raw ptr should be passed, but that's it. It's frowned upon... nay scoffed at to store references one receives as parameters, so that temporary ref will go away after the function call, leaving the smart ptr as unique owner. This should not be a problem and it…

> It's unusual to take references to the contents of a unique pointer. No, it's not. It happens every time you call a method on the referent (well, OK, this is technically not a reference, but it doesn't matter to the argument).

One is not taking the reference. When writing ptr->foo() the ref is temporary, not accessible and will be cleaned up when the method call on the raw ptr finishes.

Taking the reference would be "auto foo = ptr.operator->()". This could be forbidden by not providing op->, and instead having an apply function which takes a method name and the parameters. That would be safer, but probably too much effort for little gain.

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

#227

Post by Const-me »

oconnor663 wrote: post #208
burntsushi wrote: post #201

Earlier quoted context omitted.

> The point is, C++ allows composing these containers making higher-level ones, such as this indexed array example. What I---and others---are trying to tell you is that it's perfectly possible in Rust too. I don't think you've pointed out anything that isn't possible in Rust. My previous comment was exactly about composing containers to make higher-level ones. Have you tried building such things? Did you get stuck? M…

It seems like one of Const-me's objections is that Rust data structures like HashMap don't document a lot of guarantees about when they would and wouldn't invalidate unsafe interior pointers. That said, for Vec in particular, Rust actually makes a ton of guarantees about its layout (more that C++ std::vector I think): https://doc.rust-lang.org/std/vec/struct.Vec.html

Correct.

While vectors are comparable, C++ also guarantees a lot about the rest of the containers. E.g. unordered associative containers never expire pointers to keys or values. Linked lists never expire pointers nor iterators.

In C++ I can create an efficient LRU cache in a dozen lines of code, combining list with unordered_map::iterator}> (this implies tKey is not an int, otherwise list is more efficient). Rust’s built-in LinkedHashMap had to reimplement a linked list instead.

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

#228

Post by Const-me »

burntsushi wrote: post #201
Const-me wrote: post #200

Earlier quoted context omitted.

The exact container is not that important here. The point is, C++ allows composing these containers making higher-level ones, such as this indexed array example. They can be standard, third-party, my own, I still can compose them. About my particular example, I’m not sure you can easily implement a free list in rust, to reuse space from de-allocated items. Especially if these items have non-empty constructor and dest…

> The point is, C++ allows composing these containers making higher-level ones, such as this indexed array example. What I---and others---are trying to tell you is that it's perfectly possible in Rust too. I don't think you've pointed out anything that isn't possible in Rust. My previous comment was exactly about composing containers to make higher-level ones. Have you tried building such things? Did you get stuck? M…

> I don't see any reason why implementing a free list in Rust wouldn't be possible either.

Is placement new available in rust stable?

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

#229

Post by rurban »

rurban wrote: post #221
ktRolster wrote: post #125

Earlier quoted context omitted.

That particular problem (strlen/strcpy/memcpy) comes from the problems of the standard library string functions. It can be solved by creating your own string library. Then string manipulation is easy.

This problem was actually solved, but almost nobody uses it. Safe variants of most of those string, memory, io, wchar, stdlib and misc functions are defined in the C11 standard Annex K (finally after 9 years), but nobody is using it, and rather propose to keep using known unsafe variants like the truncating versions with an n. Like snprintf and not the safe variant sprintf_s. glibc, bsd, darwin, musl, newlib: nobody…

Done here: https://rurban.github.io/safeclib/doc/safec-3.0/d1/dae/md_do...

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

#230

Post by fulafel »

bsder wrote: post #225
fulafel wrote: post #224

Earlier quoted context omitted.

I'm going to link to pjmlp's comment who knows more about these: https://news.ycombinator.com/item?id=14700251#14701140 I was more referring to the historical perspective of how C became popular, many have fallen by the wayside. Though there are certainly current alternatives to C besides those on TIOBE. Also there are real-time extensions to current GC'd languages like Java. (Though standard C isn't very predictable…

And, with the exception of Ada and Pascal, most of those language have been dead for at least 20 years--for various good reasons. And, please do remember that Apple switched away from Pascal when writing its operating systems in spite of an enormous code base. That's pretty damning--apparently C's "undefined behavior" didn't seem to matter. So, we're back to: the only alternative to C is Ada. > Though there are certa…

I am happy with your list of languages to write an OS in, maybe add D and Oberon. I'd point out that you can also use managed languages, see MS Singularity, or the various Lisp and Smalltalk operating systems, or the UCSD P-system, etc - there is a list at https://en.m.wikipedia.org/wiki/Language-based_system .

Counting new commercial operating systems is not a useful benchmark as they are very rare, and we already agreed that the alternatives are not popular.

Post reply on HN