Hacker News Reader

Comment by oliverkwebb | Hacker News Reader

The core of C is pointer arithmetic; This creates a fundamentally unsafe environment.

You can't even do anything in C without some asm (syscall wrappers) because C was meant to boil down and streamline PDP-11 assembly (Your computer is not a fast PDP-11) to a set of consistent principles. The consequence of this is that the core of the language is pointers and pointer arithmetic, and raw unabstracted pointers are fundamentally unsafe to work with.

Using the rust type system I can essentially confirm code is bug and edge-case free with exhaustive matching and unit testing (C's lack of tooling blessed the world with autoconf and cmake btw). Not to mention rusts ability to abstract away necessary boilerplate gives me more time to think about my code instead of pointer arithmetic and allocation heuristics.

The "cure" for C is a language that abstracts away raw pointers and memory allocation.

View on HN

You can write every program you want to without pointer arithmetic.

If you mean that a dereference of a memory location involves the compiler emitting pointer arithmetic instructions -- that's true of all languages.

If you want your language to completely disguise the machine from you, and "abstract away" memory allocation, you're going to pay a high complexity cost to do so.

If you have never run C in a debugger, with the massive amount of highly sophisticated tooling available to C debuggers, then you're operating from a profoundly mistaken starting point for evaluating the viability of C for modern safe sofware development.

C debuggers and tooling are vastly more powerful than Rust's static type system, and catch a much wider array of memory problems (, and bugs) than the Rust compiler can catch. Static verification is far more limited than the dynamic verification a sophisticated debugger can perform.

People's undergrad C course is a terrible basis on which to evaluate what C is today. The reason C is associated with a lack of security is that almost all software is written in C, written in a time when either the internet didnt exist or didnt imply an adversarial local environment.

Running a network cable through every facet of our O/S and software breaks many assumptions about the entire history of programming -- which C predominated in. This is a very poor basis on which to generalize the capabilities of a well-specified C programming environment (which today, is much more powerful than Rust's compiler).

> People's undergrad C course is a terrible basis on which to evaluate what C is today. The reason C is associated with a lack of security is that almost all software is written in C, written in a time when either the internet didnt exist or didnt imply an adversarial local environment.

The problem is - undergrad C is about the lowest common denominator that all tooling understands and that all people understand. Of course you're probably not going to have to go as low as C89 like sqlite or, until 2022, the Linux kernel [1], but still, the long support cycles of many distributions make it challenging to move standards upgrades forward.

[1] https://www.zdnet.com/article/linus-torvalds-prepares-to-mov...

> C debuggers and tooling are vastly more powerful than Rust's static type system, and catch a much wider array of memory problems (, and bugs) than the Rust compiler can catch. Static verification is far more limited than the dynamic verification a sophisticated debugger can perform.

Is there any dynamic verifier that fully validates all acesses w.r.t. the object trees specified by the C standard? Tools like ASan and UBSan won't detect a write to one field running into another field, only a write overrunning the complete object. (Compiler-level hardening might catch that to some extent, but it's limited to TU boundaries.) Not to mention things like 'misuse of restrict pointers' that I've never seen any verifiers for, except for special cases like overlapping memcpy() buffers.

Meanwhile, Rust does have its own dynamic verifier, called Miri [0], which checks just about every language-level rule at runtime. The main drawbacks are that it's slow and doesn't support calling arbitrary C functions, but it would be hard to get that to work short of the Valgrind route of emulating the whole process on an instruction level.

[0] https://github.com/rust-lang/miri

If you're redoing the c std, which was my initial point, you can introduce a debug allocator with metadata about object layout. Coupled with some debugger support, i'd imagine you can get there. And if the C std was willing to allow constexpr to do more at compile time, you wouldn't need explicit debugger support and could just use constexpr to modify the compiler.

There's also nothing stopping debuggers reifying the C at debug-time into this metadata.

My claim is 95% can be fixed by just normalizing what is current practice at the stdlib level and compiler level. By extending constexpr, i think you could get to 100%. Given that this is the case, why even both with the nightmare of Rust.

Oh, you sounded like you were talking about something that already exists today, rather than something that you'd like to exist. The main problem with taking dynamic verification all the way is making it work with ABI boundaries, which won't be going anywhere in at least the next decade. You'd need everyone to migrate to a universal ABI that can convey all needed metadata, and while I've seen a few proposals for that, none of them have gone anywhere.

I was more saying that the scope of issues mainstream tooling catches, includes ones that the rust compiler doesn't catch, and many more than enough for what are common memory safety issues -- there are some issues that aren't caught, sure -- but the operations which can cause those bugs are well-defined, most programs wouldnt have to use them, and a new std lib would help.

When people propagandize about C, they're universally unaware that the normal process of development basically addresses most of the problems Rust is supposed to be solving, and more than the rust compiler alone solves. The remainder are 95% to do with libc, which should just be thrown out.

A smidge more compile-time eval with constexpr, and the use case for Rust could disappear. It's a great shame that C is run by a standards process that's determined to relegate it to electric motors and digital watches from the 80s.

> C debuggers and tooling are vastly more powerful than Rust's static type system

As someone who's worked on C debuggers and tooling... I really have no idea what you're talking about. C's core semantics are just so weak that it's not really possible to express a lot of the things you can express in the type system, and that's before we get to the necessary lossiness that debuggers and tooling have to work with (e.g., you can't just ascribe types to memory in C because C--in practice--is way too loose with types for that to be meaningful).

For an example from something I've worked on, Linux manages to have two different arrays for the GPRs for a thread register context, one that's used for ptrace and one that's used for signal contexts. Helpfully, the header files give you macros to map register names to numbers so that you can say regs[RAX] instead of regs[0]. But the offsets are different, so you have to remember that you need to use regs[REG_RAX] instead of regs[RAX], and there is absolutely no tooling in the world that can tell you when you get it wrong because there is no expressible difference between the two scenarios in C. Meanwhile, in Rust, I can wrap the accessors in newtypes so that I can only use the correct set of constants to index into the array, which makes the error state literally impossible to construct.

That's the real value of a static type system--you can use it to make errors literally impossible to specify in an API.

I don't see the difference between having a typed access API (V inline reg_at(enum K k) {} ) and overloading the indexer.

If your point is that historical C APIs have overused an untyped operation, that's part of my point about a new std lib. Rust APIs can still provide an untyped indexer, it's just bad API design.

What I'm imagining a new std lib would be doing is having debug allocators, metadata against types, etc. Ie., a std library designed for the debugger along with a release version.

Using different enums doesn't help, because C will happily let you cast enum A to enum B implicity.

In Rust, I can express an API which can't be used incorrectly. In C, I can't. Sometimes, in C, you can sometimes get to the point where you use conventions that means maybe static or dynamic analysis tools might be able to flag the misuse of the API, but very often, such tools have extremely poor tradeoffs between precision and accuracy, far worse than exists in Rust with just the vanilla compiler.

-Wconversion , no?

My point isn't that you exhaust all the features of Rust with a better stdlib and "debugger-oriented programming" -- my point is that you can get 95% of the way there with trivial complexity costs.

Rust imposes significant program design costs which can be very detrimental to otherwise trivial performant memory management, to faster iteration of software design, and so on. These aren't free lang. features.

> You can't even do anything in C without some asm (syscall wrappers)

Which language can do anything without some asm and support as many platforms as C?

> Which language can do anything without some asm and support as many platforms as C?

I wouldn't be surprised if someone figured out how to do the interrupts and register control necessary to invoke syscalls with pure LISP/Scheme/CL :P

P.S. anything that compiles with LLVM and has an ingrained way to do print() that doesn't invoke libc, although there's a blurry line here between "pure asm"/"compiles to asm" that involves trusting-trust-style bootstrapping of features into the compiler

You don't know what you're talking about

> > Which language can do anything without some asm and support as many platforms as C?

> I wouldn't be surprised if someone figured out how to do the interrupts and register control necessary to invoke syscalls with pure LISP/Scheme/CL :P

Haha

> P.S. anything that compiles with LLVM and has an ingrained way to do print() that doesn't invoke libc, although there's a blurry line here between "pure asm"/"compiles to asm" that involves trusting-trust-style bootstrapping of features into the compiler

Actually LLVM IR has no concept of syscalls, you have to use inline assembly inside your IR to issue syscalls.

What haha; we had that decades ago: systems programmed in Lisp from the bare metal.

Here is what assembly code looks like in (ccl) Clozure Common Lisp:

https://github.com/Clozure/ccl/blob/master/level-0/X86/x86-h...

ARM version of same file:

https://github.com/Clozure/ccl/blob/master/level-0/ARM/arm-h...

Reply on news.ycombinator.com