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

Getting Past C

blog.ntpsec.org

Post reply on HN
Print view View original

161–170 of 504 posts

Re: Getting Past C

#161

Post by dbaupp »

dreta wrote: post #140
dbaupp wrote: post #128

Earlier quoted context omitted.

The lack of generics means your array implementation is either going to either: - be implemented with macros and token pasting, and result in a ton of mental overhead because you'll have a pile of types like array_foo for an array of `foo`s, and array_bar for an array of `bar`s, along with a pile of corresponding `foo * array_foo_get(array_foo, size_t)` and `bar * array_bar_get(array_bar, size_t)` functions. - or, ha…

No, you just allocate enough space to store an extra int at the start for the length, and return a typed pointer to the actual data. Then you need an accessor that checks bounds, if you want safe access. Both of these problems are solved by simple macros.

So you want the array to have type foo * ? Ignoring that this doesn't let the compiler help the programmer with arrays (you still have to manually remember to use the accessor, not []), you also have to manually remember which pointers are pointers and which are arrays, and this representation doesn't work for pointing into subsections of an array (a similar problem to C-style strings), nor does it work well for putting arrays on the stack, which means one is forced to allocate every array (both of which mean the safe C is likely slower than the equivalent in Rust or even C++).

Re: Getting Past C

#162

Post by ArkyBeagle »

pjmlp wrote: post #151
ArkyBeagle wrote: post #72

Earlier quoted context omitted.

C is the new "goto". Y'all please, please note that dreta said "... an array implementation that prevents that from ever happening..."

C is the PHP and JavaScript of the 70's.

:) I don't know anything about either.

Re: Getting Past C

#163

Post by staticassertion »

sidlls wrote: post #147
EugeneOZ wrote: post #133

Earlier quoted context omitted.

Rust is safe in terms of memory usage and race conditions, nobody claims that Rust compiler will catch all 100% of bugs human can invent.

Rust is safe by default in terms of memory usage. It is not, however, strictly memory safe. It is trivial to overflow a buffer in Rust, for example. I haven't discovered a trivial way to hide it, though.

In safe rust it is definitely not trivial to overflow a buffer in a way that violates memory safety.

Re: Getting Past C

#164

Post by Manishearth »

jdmichal wrote: post #59
lacampbell wrote: post #46

Earlier quoted context omitted.

I never made the argument that you shouldn't use a safe GC'd language. I merely made the argument (now flagged for whatever reason) that buffer overflows are an easily solvable issue in C, and if you are having issues with them you really need up your game and learn to create abstractions. As for the cost of the abstraction of bound checked arrays of arbitrary length, I can't imagine it being any slower than rust. I…

Obviously, if you have to check an index length you're going to be doing a branch. However, because the index checks are intrinsic to the Rust compiler, it can remove them when it proves the code is safe. So, for instance, an iteration loop over an array won't have any index checks in the generated machine code.

> because the index checks are intrinsic to the Rust compiler

This is false. The index checks are written in Rust code as an impl of the Index trait on [T].

The checks being removed have nothing to do with this -- LLVM can prove that certain checks are unnecessary. C does the same, if you used a library that provided checked indexing.

What's different is that in Rust indexing is overall used much less often, because iterators are the dominant pattern, which completely sidesteps this pattern.

Re: Getting Past C

#166

Post by staticassertion »

EugeneOZ wrote: post #131
staticassertion wrote: post #40

Earlier quoted context omitted.

Because your 'safe' implementation will certainly have a performance cost, and won't be the default. This is why, despite C++ providing std::array, you'll still find buffer overflows in C++ code. C++'s std::array provides the safe 'at' function but you're opting into a performance penalty and it's not the more familiar [] syntax. Rust arrays/ vectors are safe-by-default. To use the unchecked, unsafe version requires…

No, Rust arrays are not safe by default: https://is.gd/iY5lPQ

Panics do not violate memory safety. In C that code would be undefined behavior.

Re: Getting Past C

#167

Post by sidlls »

steveklabnik wrote: post #149
sidlls wrote: post #147

Earlier quoted context omitted.

Rust is safe by default in terms of memory usage. It is not, however, strictly memory safe. It is trivial to overflow a buffer in Rust, for example. I haven't discovered a trivial way to hide it, though.

If Rust is not memory safe in safe code, then you've found a bug. Please report it to https://www.rust-lang.org/security.html

Let me clarify: in Rust it is trivial to use memory unsafely. It is not, so far as I have found, trivial to hide that fact because it is required to use "unsafe" syntax decoration" to do so.

Re: Getting Past C

#168

Post by pjmlp »

lossolo wrote: post #155
pjmlp wrote: post #148

Earlier quoted context omitted.

Not all OSes have unsafe syscalls, nor do all OSes have to be implemented in C.

But the most used are and I can't see it change anytime soon.

Hence why it is about time to change the status quo.

Re: Getting Past C

#169

Post by Manishearth »

lacampbell wrote: post #105
pjmlp wrote: post #77

Earlier quoted context omitted.

I have been hearing and reading that from C advocates since 1993. It only got worse.

Not an argument, or even a point. I don't know why this is so difficult for people to understand. Buffer overflows are easy to avoid in C. I think I recognise your name from some rather aggressive rust advocacy in another thread, so I'll try and break this down in a way that won't trigger you: - Buffer overflows are trivial to avoid in Rust, AFAIK. I acknowledge this - Buffer overflows are very easy to code in C, and…

> if you provide your own thin abstractions

Without generics these abstractions are hard to work with and hard to make work across libraries. I am reminded of https://thefeedbackloop.xyz/i-bet-that-almost-works/

> Take the rust compiler itself: AFAIK it's now implemented in C++

The compiler is written in Rust. It uses LLVM, which is in C++, for codegen, but in the future we might be able to turn that off too (https://internals.rust-lang.org/t/possible-alternative-compi...)

Besides, the implementation language of a compiler does not make the compiler an "abstraction" over the language. Sort of, but not really.

Re: Getting Past C

#170

Post by derefr »

steveklabnik wrote: post #149
sidlls wrote: post #147

Earlier quoted context omitted.

Rust is safe by default in terms of memory usage. It is not, however, strictly memory safe. It is trivial to overflow a buffer in Rust, for example. I haven't discovered a trivial way to hide it, though.

If Rust is not memory safe in safe code, then you've found a bug. Please report it to https://www.rust-lang.org/security.html

If you're relying on any random third-party Rust crates you haven't audited yourself, don't you lose the safety guarantee? A given crate might turn out to have implemented operations on some data-structure using unsafe blocks, and then to have failed to mark its own API functions as unsafe in turn (like the Rust stdlib does, but without the "extensive manual auditing" that the stdlib gets).

AFAIK, cargo doesn't have any feature to point out when a crate contains unsafe code—so you pretty much need to grep the source of every crate you consume for "unsafe".

Post reply on HN