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

431–440 of 504 posts

Re: Getting Past C

#431

Post by ArkyBeagle »

nickpsecurity wrote: post #242
ArkyBeagle wrote: post #160

Earlier quoted context omitted.

Final word on the subject - what we have is people who are trying to make Open Software Reputation Points by finding a problem and fixing it, rather than waiting to find a real problem and fixing that. When the figure of "ten minutes" was used - that's really what it should be as a mean or median figure, with some long-tail outliers for knotty cases. While I am (somewhat) sympathetic, I don't miss what it is - it's m…

I see where you're going with this. I normally would agree. In this case, we have a large, C program that evolved over time for a complicated feature set. That they trimmed that much fat out might already be saying something about how much risk might be in that code. It's also been around a long time in important infrastructure plus will continue to be. Converting it to something that's safer in most ways, esp dynami…

Yep. It's always about "the space between the buttons" in code bases. That's not pretty; I know that. It's a huge source of human suffering. But I wonder how reducible it truly can be. As they say, its (still) early days yet.

That (email thing) would be awesome, Nick. Thanks.

Re: Getting Past C

#432

Post by awinter-py »

enriquto wrote: post #391
awinter-py wrote: post #247

Earlier quoted context omitted.

agree -- inability to do variable-sized arrays on the stack is the root of the problem.

What do you mean? Variable-length arrays are OK in C.

oops -- you're right.

https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html

Legal in C99, available in C++ on gcc/clang.

Re: Getting Past C

#433

Post by Matthias247 »

falcolas wrote: post #38
leoedin wrote: post #18

Earlier quoted context omitted.

Microcontrollers aren't moving towards application level processors like the Raspberry Pi uses, they're moving towards low power ARM cores like the Cortex M0/M3/M4. It's not clear to me why you'd choose an AVR for a new product unless you really, really needed a specific feature. Current generation ARM Cortex M0 devices are available at a similar cost and with significant performance gains, with the benefit that if y…

I'd love to read more about this microcontroller migration towards ARM - any hints on where to look?

I don't have a single source about this. But some hints are: 10 years ago every µC manufacturer had it's own core and instruction set and basically sold them exclusively (maybe apart from some 8051 stuff). They were AVRs, PICs, V850, PPC, etc. Now when you look that the portfolio of those manufacturers they nearly all have at least one product with an ARM core in their portfolio. Some might even already stopped releasing new chips with their proprietary cores. Others have done that not yet but are planning to do this in the future (I've heard of at least one).

Another hint is when you actually get in touch with a lot of complete product designs. The amount of ARM cores that you will see in there seems steadily to incline.

Re: Getting Past C

#434

Post by pjmlp »

ue_ wrote: post #419
kqr wrote: post #392

Earlier quoted context omitted.

> I work on a C codebase that does this […]. Yes, there is quite a lot of NIH. With essentially-uniform use of checked data structures, and an extremely comprehensive suite of automated tests getting run under ASAN (originally Valgrind) […]. This is a complex, >1M SLOC distributed system that has seen several years of production use at this point […]. > > […] it just needs to be done from the start, and then you just…

But Rust still won't warn about an out of bounds access (when accessing using a variable) at compile time, and your code will panic at runtime. This isn't the "safety" anyone ought to be expecting from a language billed incessantly as safe. Rust, at least in this regard and probably others too, is no better than C, and for me it isn't enough to justify the horrible and complex syntax.

Safety has to do with memory corruption that lead to security exploits and unrecoverable data, not panics.

Re: Getting Past C

#435

Post by eggy »

I didn't see Ada or ATS mentioned upon a quick read here. I don't program in either beyond exploratory play, but they seem to fit the need here no?

Re: Getting Past C

#436

Post by pjmlp »

enriquto wrote: post #391
awinter-py wrote: post #247

Earlier quoted context omitted.

agree -- inability to do variable-sized arrays on the stack is the root of the problem.

What do you mean? Variable-length arrays are OK in C.

Not in C11, they were removed due to security issues and became an optional language feature.

Re: Getting Past C

#437

Post by pjmlp »

awinter-py wrote: post #432
enriquto wrote: post #391

Earlier quoted context omitted.

What do you mean? Variable-length arrays are OK in C.

oops -- you're right. https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html Legal in C99, available in C++ on gcc/clang.

Optional in C11, not accepted in ANSI C++17.

Re: Getting Past C

#438

Post by nurettin »

kbenson wrote: post #371
nurettin wrote: post #351

Earlier quoted context omitted.

The title is Rust-bait so let's all chant rust! Rust! RUST! Oh but there are only three tentative mentions of Rust in it and this entire comment section is corroded. Just compare the two pages in a browser with ctrl-f rust

I'm not sure where you're under the impression that the number of times something is explicitly mentioned corresponds directly to the number if times it's being discussed, which is what is implied by your suggestions to search for occurrences of the name. The whole article is about future plans for NTPsec, and the work going into making it so it can be converted to a new language later. The article is about the relat…

For me, this is the gist of the article:

>> But NTPsec is a lot smaller and cleaner now at 62KLOC of C (that’s just 27% of the original size). It’s been brought up to pretty tight C99/ANSI standards conformance, and the few remaining platform dependencies are either already well isolated or can easily be made so.

Then they have a section about future plans and a short comparison of two possible languages. I'm surprised that you're surprised Go is virtually non-existent in this thread.

Hackernews comment sections are strictly for endlessly typing about Rust's memory safety features to seemingly no end. You will find this behavior under any article that mentions C or C++.

At this point I don't care about downvotes because the whole finding-valuable-comments-to-learn-from experience I've had in the past is getting harder and harder to attain to. So instead of bitching about that, I will just go upvote someone who is downvoted.

Re: Getting Past C

#439

Post by gcatlin »

aduffy wrote: post #257
steveklabnik wrote: post #237

Earlier quoted context omitted.

It is by definition a "zero-cost abstraction." Let's ask Stroustrup, who coined the term: > C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better. Two points: What you don't use, you don't pay for: if you don't use array indexing, you won't get a bounds check. In addition, you can call an access method without a bou…

This is actually a very helpful comment. I used to think "zero-cost" meant "at compile-time", as in `newtype` in Haskell, etc. I'm guessing that's what the parent commenter thought as well, and I'd guess is what most people think when they hear the phrase.

I think that's why Stroustrup says "zero overhead" instead of "zero cost". There are costs to many of these abstractions; some at compile time and some at run time. For me, "zero overhead" conveys this a little better.

Re: Getting Past C

#440

Post by pjmlp »

ArkyBeagle wrote: post #430
mden wrote: post #287

Earlier quoted context omitted.

But adding functionality grows in effort as more code is added. At some point it makes sense to improve a code base so you improve the rate at which you are getting "there". In fact there are a lot of code bases, perhaps most, which simply cannot get there in any sane way and fall short of achieving their goal. You might not care how goals are achieved as a user but as an engineer it's worth exploring and discussing…

I care more as a user than as an engineer. :) Just to be clear - I don't suspect that the things that pretend to replace C are bad, or no good. I've just seen multiple "pretenders to the throne"[1] and what would appear to have happened is that we just moved the pathology around. [1] please excuse the horrible metaphor. After a few iterations of that, one begins to think that perhaps this is a distinctly human proble…

> There's no real repository of literature to actually address any of this - each engineer appears to have to learn it mostly from scratch.

It is called university and engineering degree in software development.

Post reply on HN