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

131–140 of 504 posts

Re: Getting Past C

#131

Post by EugeneOZ »

staticassertion wrote: post #40
dreta wrote: post #27

Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? I do agree that C has issues (though in my opinion neighter Rust nor Go address almost any of them) i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up w…

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

Re: Getting Past C

#132

Post by pjmlp »

jdmichal wrote: post #47
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…

In addition, the Rust compiler can also remove the built-in indexing checks if it can prove the code is safe. So, say, iterator loops over an array won't have any index checking.

Compilers for Pascal dialects, Ada and Modula-2 were already doing that in the early 90's.

Re: Getting Past C

#133

Post by EugeneOZ »

staticassertion wrote: post #104
sidlls wrote: post #76

Earlier quoted context omitted.

How do you suppose runtime bounds checks are done in Rust? They certainly also incur a performance penalty in not-trivial cases. Also, "safe by grep audit" means "safe according to a human." The argument of course is that it lowers the surface area of what a human must be trusted to verify. I'm still not convinced by that argument, because human error is a thing. And for actual systems programming, "very rare" may no…

> How do you suppose runtime bounds checks are done in Rust? They certainly also incur a performance penalty in not-trivial cases. Certainly. I didn't intend to imply otherwise. > Also, "safe by grep audit" means "safe according to a human." Again, totally correct here. > The argument of course is that it lowers the surface area of what a human must be trusted to verify. I'm still not convinced by that argument, beca…

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.

Re: Getting Past C

#134

Post by jstimpfle »

nathyong wrote: post #122
jstimpfle wrote: post #82

Earlier quoted context omitted.

Some people don't believe in tweaking GC's. I've heard horror stories from people who tried it on the JVM. (And I have made terrible experiences with JVM's GC, but never tried tuning). Some people don't believe that extremist functional languages are needed (depending on the domain). Validation. Oh, well. I think you propose Haskell, and it might disqualify for an NTP daemon, for example in terms of debuggability (st…

A more relevant point that would disqualify Haskell is the fact that its runtime (or rather, the GHC's runtime) is nowhere near predictable enough for the realtime guarantees that time synchronisation software would require. A Haskell DSL that outputs some safer low-level code would be a more likely choice (for example http://hackage.haskell.org/package/atom ), but Rust is both more popular and has more commercial su…

When opting for a DSL that compiles to low-level the "Haskell" part is less important.

I've heard the idea of DSLs over and over again, but who actually does that? I know of course of sed, awk, regex, etc but what part of NTPsec is narrow enough in scope and large enough in volume to justify creating a DSL? (just asking -- I'm not familiar with NTPsec).

Re: Getting Past C

#135

Post by eridius »

mitchty wrote: post #80
eridius wrote: post #64

Earlier quoted context omitted.

There is a lot of community interest in Rust with regards to running on embedded devices, so I wouldn't be so quick to point to IOT devices as a reason for not using Rust. That said, I don't know what the current state of support for these less popular architectures is. The official page for platform support is https://forge.rust-lang.org/platform-support.html .

LLVM's biggest weakness right now is micro controller support like PIC/AVR. But its getting better: http://lists.llvm.org/pipermail/llvm-dev/2016-November/10717... That should hit most of the chips most people would care about. I presume rust would gain from the upstream LLVM support?

Yeah it should. AIUI Rust uses a fork of LLVM, but they should be regularly pulling in upstream changes (but I don't know how often this happens) as well as submitting their own changes back upstream.

Re: Getting Past C

#136

Post by steveklabnik »

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 are definitely safe. They are significantly different than the segfault you'd get out of the C code.

Re: Getting Past C

#137

Post by steveklabnik »

eridius wrote: post #135
mitchty wrote: post #80

Earlier quoted context omitted.

LLVM's biggest weakness right now is micro controller support like PIC/AVR. But its getting better: http://lists.llvm.org/pipermail/llvm-dev/2016-November/10717... That should hit most of the chips most people would care about. I presume rust would gain from the upstream LLVM support?

Yeah it should. AIUI Rust uses a fork of LLVM, but they should be regularly pulling in upstream changes (but I don't know how often this happens) as well as submitting their own changes back upstream.

We do, in both directions.

Re: Getting Past C

#138

Post by decebalus1 »

pklausler wrote: post #25

Honestly, why not do it once and for all in a strongly typed pure functional language, validate it, and then tweak the GC parameters to get the performance? Use the safest and most powerful language that you can, if you can.

> strongly typed pure functional language > tweak the GC parameters to get the performance

Care to give an example of such a language which allows for a guaranteed GC pause\resume configuration\declaration\etc in a critical section?

Re: Getting Past C

#139

Post by EugeneOZ »

panic wrote: post #69
jdmichal wrote: post #66

Earlier quoted context omitted.

Obviously, one can program C to do anything, and write all the provably safe abstractions wished. But, that's not really the point. The point is that doing such is not the default. It requires engagement and knowledge of the programmer, especially on distributed projects with loose communication, such as many open source projects. And it only takes one programmer mistake to bring the whole house of cards down. Why al…

And it only takes one programmer mistake to bring the whole house of cards down. Isn't this also true of Rust, with its unsafe keyword? None of these languages are completely safe against programmer mistakes.

Even without `unsafe` programmer can make mistakes in Rust. Logical mistakes are unstoppable.

Re: Getting Past C

#140

Post by dreta »

dbaupp wrote: post #128
dreta wrote: post #27

Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? I do agree that C has issues (though in my opinion neighter Rust nor Go address almost any of them) i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up w…

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.
Post reply on HN