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

The Case for Memory Safe Roadmaps

nsa.gov

Post reply on HN
Print view View original

411–420 of 427 posts

Re: The Case for Memory Safe Roadmaps

#411

Post by LoganDark »

munk-a wrote: post #173
LoganDark wrote: post #165

Earlier quoted context omitted.

Do "references" even exist in C? Aren't they a C++ thing? How do you manage heap allocations without ever touching a pointer?

Edited for correctness - I was indeed talking about C++ and references are relevant only in C++. C absolutely has stack allocations which can make things a fair bit safer but if you're passing around collections it's usually done by pointer just to avoid copy actions.

C has VLA, but I think C++ can still use alloca, although that returns a pointer still.

Re: The Case for Memory Safe Roadmaps

#412

Post by jandrewrogers »

trealira wrote: post #410
jandrewrogers wrote: post #408

Earlier quoted context omitted.

I wasn’t necessarily assuming ‘-ftrapv’. For reliable software in C++ it is pretty common to have alternative integer type implementations that provide different fully defined behaviors and guarantees than the default integer types. This became legitimately transparent around C++17 IIRC. It is more or less drop-in and mostly produces optimal codegen. Also a good way to eliminate irritating integer behaviors inherited…

> For reliable software in C++ it is pretty common to have alternative integer type implementations that provide different fully defined behaviors and guarantees than the default integer types. This became legitimately transparent around C++17 IIRC. It is more or less drop-in and mostly produces optimal codegen. Also a good way to eliminate irritating integer behaviors inherited from C. I didn't know this. I can imag…

Yes, this is one of the advantages of pervasive operator overloading in C++. You can create types that behave like primitive integral types for all practical purposes but which implement alternative behaviors like trapping overflow, blocking integer promotion, defining shift operators greater than or equal to the bit width, creating alternative casting rules, etc. However, it has not always been possible to implement this transparently in C++.

This did not work well in older versions of C++ because the limited type inference meant that many common cases around different type interactions required explicit handling that made it clear you were not using native types. Around C++17 it became possible to define integer types that were almost entirely indistinguishable from the native types in ordinary C++ code.

C++17 was important because it meant a lot of safety in the code base could become automagic via the type system, especially for primitive types. The code looks the same whether you are using it or not. That was a huge capability change. C++20 then generalized it to arbitrarily complex types. It is difficult to overstate how much this improves the conciseness and safety of non-trivial code.

Re: The Case for Memory Safe Roadmaps

#413

Post by caskstrength »

eternityforest wrote: post #405
caskstrength wrote: post #338

Earlier quoted context omitted.

> If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. It is not only or even mostly legacy. I'm a systems programmer (in classical sense, not "but my web service is soooo highly loaded and scalable that I will call it systems programming!") and from what I see on the job people start new projects in C an…

Why do they choose C/C++? Is it just what they and their colleagues already know and nobody wants to be the one to push for change? Easier integration with other C/C++ stuff?

From my experience reasons differ for C and C++ programmers.

C programmers are often more experienced people who are used to "simple" language that gets out of the way. They don't want to invest time into learning tricky language like Rust with all the intricacies of its type system, borrow checker, etc. Something simpler like Zig might work for them, but it is not on the table at the moment.

C++ programmers tend to be people who spent hundreds if not thousands of hours learning its ugly corner cases, reading Meyers and Alexandrescu books, that kind of thing. Sunken cost is immense, they whole careers are built on being "C++ experts" and they dread to abandon it and have to learn another very complex language from scratch.

And managers often don't see value in investing time into switching projects to new language. From their PoV it is more like programmers just want to play with a new toy instead of doing "real work".

Re: The Case for Memory Safe Roadmaps

#414

Post by edwcross »

ryao wrote: post #340

It is a shame that there is no open source equivalent to tools like Astree: https://www.absint.com/astree/index.htm In theory, it is possible to write completely memory safe code in C/C++ using it. As long as its analysis generates no complaints, there are no memory safety issues in the analyzed code.

I beg to differ: there are a few tools which are comparable.

Frama-C (https://www.frama-c.com) is an open source framework that has, among its analyzers, one based on abstract interpretation (https://www.frama-c.com/fc-plugins/eva.html) that is very similar in spirit to Astree.

MOPSA (https://mopsa.lip6.fr) is another open-source project (albeit more recent, and in a more "academic" stage) that also provides abstract interpretation to analyze C programs for flaws.

NASA also released IKOS (https://github.com/NASA-SW-VnV/ikos), on the same vein.

Of course they lack the polish of a product which costs tens of thousands of euros per license, but they are open source, and their purpose is the same: to ensure code safety via formal methods, in particular abstract interpretation.

It is possible to get these tools to analyze some code and generate no complaints, which ensures absence of several kinds of problems, such as memory safety issues.

Then again, it's hard to know exactly how much they differ from Astree, since you need a license to compare them, and I don't even know if you are allowed to publish such comparisons.

Re: The Case for Memory Safe Roadmaps

#415

Post by pjmlp »

synergy20 wrote: post #366
BaculumMeumEst wrote: post #224

In the world of graphics programming, you've got: - continuing accumulation of documentation and utility libraries from Khronos - excellent learning materials from the community - tons of legacy code all using C++. https://github.com/KhronosGroup/Vulkan-Utility-Libraries https://github.com/cg-tuwien/VulkanLaunchpad https://cescg.org/our-services/an-introduction-to-vulkan/ Until I see professionals get funding to buil…

The industry did not abandon C and C++ for Ada in the past, likely it will do the same to Rust. Not to mention C and C++ are both evolving and their toolchains are getting much better nowadays. After using Rust for a while, I actually decided to stay with to c/c++ for the rest of my career.

Only because there weren't affordable compilers, everyone was cloning UNIX, and there weren't goverment mandates for the industry at large.

There are still COBOL and Fortran developers, C and C++ won't go away tomorrow, even if the goverment says so, but it will be harder to use them in security clearance contexts, similar to hazardous goods.

Re: The Case for Memory Safe Roadmaps

#416

Post by pjmlp »

angiosperm wrote: post #384
BaculumMeumEst wrote: post #224

In the world of graphics programming, you've got: - continuing accumulation of documentation and utility libraries from Khronos - excellent learning materials from the community - tons of legacy code all using C++. https://github.com/KhronosGroup/Vulkan-Utility-Libraries https://github.com/cg-tuwien/VulkanLaunchpad https://cescg.org/our-services/an-introduction-to-vulkan/ Until I see professionals get funding to buil…

Importantly, if you look at lists of "C/C++" security holes, you find it is almost all C security holes. So when they write "C/C++" they are hoping you won't notice they are lying to you. The residue of holes in C++ code is about the same as JS, Python, etc. So just eliminating C and C-like constructs gets you to the same level of security as the other languages.

Those C security holes are C++ security holes, since the day C++ decided to be a TypeScript for C.

Re: The Case for Memory Safe Roadmaps

#417

Post by rcxdude »

worthless-trash wrote: post #403
angiosperm wrote: post #384

Earlier quoted context omitted.

Importantly, if you look at lists of "C/C++" security holes, you find it is almost all C security holes. So when they write "C/C++" they are hoping you won't notice they are lying to you. The residue of holes in C++ code is about the same as JS, Python, etc. So just eliminating C and C-like constructs gets you to the same level of security as the other languages.

The way you have phrased this is very disingenuous. > Importantly, if you look at lists of "C/C++" security holes, you find it is almost all C security holes. So when they write "C/C++" they are hoping you won't notice they are lying to you. As these "C-isms" are part of the base language, and you cant 'opt out', this means the base language is still included in the lists. Most C++ applications still linked (and used…

modern-ish C++ has some tools that can make it easier, but fundamentally it's still unsafe, it's still proven pretty difficult to write a large C++ codebase without memory safety issues. (that said I would still personally prefer C++ to C, though the recent updates to the standard contain at best very small improvements from my point of view)

Re: The Case for Memory Safe Roadmaps

#418

Post by rwmj »

petabyt wrote: post #407
rwmj wrote: post #85

Given the vast amount of C/C++ around, much which will never be rewritten, I wonder if bounds checking compilers should be considered?

We've had bound checks and address sanitizers in most C compilers for years now at this point (gcc, tcc, clang)

I know, I wrote the first one for GCC.

Re: The Case for Memory Safe Roadmaps

#419

Post by IlliOnato »

wolvesechoes wrote: post #142
helsinkiandrew wrote: post #86

Earlier quoted context omitted.

And many buildings were built deliberately poorly to make a quick buck - or caught fire too easily or fell down in minor earthquakes (or worse damage other property/people). Peoples homes are a major financial commitment and can ruin people if they're not up to scratch. The regulations are to ensure the 10% of bad builders/developers don't ruin peoples lives.

And yet, poorly build buildings are still being build, but at least now it is much harder and much more expensive for a person to build their own house, and for a small construction companies to compete with giant monopolies. Yay!

Well, it's not black and white.

Regulation hinders progress and makes things more expensive. But no regulation raises costs and hinders progress too: it basically creates a situation of very low trust, and low trust is extremely expensive for customers/buyers who are not domain experts. This also makes them overcautious and conservative. One needs a balance and lots of nuance to make a reasonably well functioning market/system.

The case against regulation on software business is not that "regulation is bad". It's that programming and software is very new and rapidly evolving area of human activity. It's not nearly as well understood as building houses. Written and unwritten standards and best practices are constantly changing. The field is subject to very strong fashion-driven "crazes".

(Just look at how many new languages are still being created. Most don't become as widespread as C++ or Java or Python, but many do find their niche, and very many are in use to some extent. This indicates that "language Holy Graal" is nowhere to be seen yet.)

In software, there is very little consensus between domain experts on most issues. This is very unlike construction and house building, where some new materials ant techniques are introduced too, but the basic principles are well understood, calculable, and where agreement among experts is usually quite achievable.

So arguably it's nearly impossible to create good regulation at this stage, at least outside of certain special niches. This is very different from building codes and stuff.

Of course there is also bad regulation. The bureaucracy likes to expand their control indefinitely, wants to regulate things that should not be regulated, thus (if unchecked) creating very bad regulation. Well, that's the case for checks and balances, for the society to fight back. But "this regulation is bad and needs to be changed" is a much more mature position than "we need no f*g regulation!", in my opinion...

Re: The Case for Memory Safe Roadmaps

#420

Post by trealira »

vips7L wrote: post #395
trealira wrote: post #355

Earlier quoted context omitted.

> Doesn't OpenJDK install a SIGSEGV handler, and generate the exception from that on a null dereference? I thought I had read that they explicitly don't do that, but I can't find it anymore. You may be right. I should have checked before saying that. > (AFAIK, a lot of runtimes for GC'd languages that support thread-based parallelism do so anyway, because they can use mprotect to do a write barrier in hardware.) That…

> I thought I had read that they explicitly don't do that This is exactly what they do: https://shipilev.net/jvm/anatomy-quarks/25-implicit-null-che... When this happens it'll cause a deoptimization and recompilation of the code to include the null check rather than rely on the signal handler repeatedly.

Thanks for the link!
Post reply on HN