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

Memory Safe Languages in Android 13

security.googleblog.com

Post reply on HN
Print view View original

491–500 of 606 posts

Re: Memory Safe Languages in Android 13

#491

Post by pizza234 »

clnq wrote: post #350
Tuna-Fish wrote: post #327

Earlier quoted context omitted.

> As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously Are you serious? A bad workman blames his tools, because workmen are reponsible for their tools . A large part of being a good workman is identifying what tools are good and using them. And C++ is a terrible tool for any task where you are not forced to use it because of existi…

> A bad workman blames his tools, because workmen are reponsible for their tools. A large part of being a good workman is identifying what tools are good and using them. As I said in the comment to which you are responding, "selecting the correct tool for a job is more important than figuring out which tool is better in some abstract way." > C++ is a terrible tool for any task where you are not forced to use it Many…

> For small projects, I could agree. What would your recommended alternative be for massive codebases in large tech companies that need fast and efficient code?

The poster wrote very clearly:

> where you are not forced to use it

If one is forced, there's obviously no option.

The idea is not that C/C++ should be replaced right now, rather, that devs finally understand that C/C++ should not be used where possible.

I actually see this pattern used by some, who defend C/++: "C/++" should be deprecated" - "No, it's impossible to eliminate C/++ today".

Deprecation is not elimination. Linux started introducing it, and Google is doing as well, so it can be done gradually.

Re: Memory Safe Languages in Android 13

#492

Post by Thiez »

maeln wrote: post #14
thesuperbigfrog wrote: post #11

Earlier quoted context omitted.

>> Actually now is the time to learn C++. Amount of leverage and money C++ developers will be able to utilize is enormous, given how much critical code is written in it. The article states: "We continue to invest in tools to improve the safety of our C/C++. ... Vulnerabilities found using these tools contributed both to prevention of vulnerabilities in new code as well as vulnerabilities found in old code that are in…

I think he meant it in a way the same way that some people are still learning COBOL: a lot of critical, legacy code is written in C++ and cannot easily (or won't be for various reason) moved to another langage. Therefore, developer that can maintain a C++ codebase might become invaluable for some company.

The COBOL developers might be invaluable, but statistically their pay does not reflect this at all. Is there any reason to believe it will be different for C++, if it were to become a legacy language?

Re: Memory Safe Languages in Android 13

#493

Post by kaba0 »

steveklabnik wrote: post #485
kaba0 wrote: post #409

Earlier quoted context omitted.

> You need unsafe. You beed it for that feature. It is questionable whether you really want to mandate a special memory layout (because you can’t really do that even in Rust, you don’t have explicit control of struct alignments, paddings, order(!) )

Rust absolutely gives you control over alignment, padding, and ordering. It’s just not the default. Ask for those things and you shall be given it.

Could you point me to some resources on that? I only know about #[repr] options, but that isn’t absolute control (e.g. for having structs usable from rust and internal asm)

Re: Memory Safe Languages in Android 13

#494

Post by pizza234 »

josefx wrote: post #460
simiones wrote: post #443

Earlier quoted context omitted.

> > if the programmer is "smart enough". > Can't defend this, but tbh I've never heard it. Take a look at this comment: https://news.ycombinator.com/item?id=33824934 > Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. It is a somewhat common attitude in this type of thread.

> It is a somewhat common attitude in this type of thread. Except the safety features are often a lot easier to use than the original C isms that tend to cause the most issues. So it is less an issue of smart and more one of bad habits. C strings instead of std::string, plain arrays instead of std::vector, implicit ownership instead of smart pointers, ... .

The stats come from Google project(s) - you can be sure that they've used the best practices. If they've failed, rest assured that 90%+ of the rest of the devs will fail, and much worse.

Re: Memory Safe Languages in Android 13

#495

Post by tialaramex »

pjmlp wrote: post #456
tialaramex wrote: post #346

Earlier quoted context omitted.

You would definitely need to control for domain. A Rust library for some sort of mathematical modelling might well need no unsafe at all, while a Java library for controlling some hardware might soon turn into JNI talking to some C++ code and oops you're unsafe. In C# you need to reach for unsafe to do some of the stuff Rust can just do safely anyway. Did you know a C# struct with an array of 8 ints in it, doesn't ac…

It does if you learn to use C# properly, https://learn.microsoft.com/en-us/dotnet/api/system.runtime.... In actual native code produced by RyuJit, you don't need to worry about cache lines for single instances, because the struct might not even exist at all, the Jit having mapped fields into CPU registers instead. When it matters, like the struct being part of an array, use StructLayout.

That link seems like it's about alignment rather than about arrays inside structures?

Re: Memory Safe Languages in Android 13

#496

Post by bitexploder »

kaba0 wrote: post #396
Ar-Curunir wrote: post #255

Earlier quoted context omitted.

Google is one of the biggest C++ shops out there, and also authors and maintains many of the static analysis tools and safety features you mention. If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

Google’s C++ coding guide is (was?) not really up-to-date, so there is that. Modern C++ is indeed a huge upgrade on what came before and with a good amount of static and dynamic analysis the state of low-level programming is much better now, but there really is no reason for new programs to be written with these . Besides the bottom of the stack, managed languages are more than fast enough for nigh everything.

Never mind you don’t give up any performance to use Rust anyway. They focused heavily on only incorporating features with zero cost abstractions.

Re: Memory Safe Languages in Android 13

#497

Post by kaba0 »

burntsushi wrote: post #465
kaba0 wrote: post #406

Earlier quoted context omitted.

Well, there is still an important difference between Java and Rust — are you driving with a guardrail on a field vs are you driving next to a cliffhanger. The JVM has well-defined bad execution as well, e.g. data racing is well-defined. Safe Rust does prevent data races statically, but if they do happen due to a bad unsafe block, you are entirely on your own. While memory safety can abruptly stop both processes, FFI…

I don't have much Java experience, so I'll have to take your word for it. But it's not completely obvious to me that you're correct. We've moved from an absolutist idea of memory safety to trying to build an implicit ontology of tiers of memory safety based on usage. Now you're talking about going and doing surveys of code and trying to measure the relative frequency of certain things and then using that to drive a t…

As others mentioned, there is no absolute safety, nor memory, no anything. The hardware can have bugs, the verification toolkit can have, or the properties to be verified could have been incorrectly specified to begin with.

I’m just saying that corrupting the heap is much easier with Rust than with Java, and there is no coming back from heap corruption on a process basis, while most exceptional cases are recoverable by the JVM (hence the cliff analogy).

And Java can have surprisingly good performance, especially in multi-threaded code that has a non-predictable allocation pattern (where ARC is just not too good) — if you want significant performance improvements you really have to go down the inline asm road, which you can do from anywhere.

Re: Memory Safe Languages in Android 13

#498

Post by jackmott »

stonemetal12 wrote: post #39
insanitybit wrote: post #8

Glad to see robust work here. This strongly supports what should already be obvious, but sadly is not always understood; that memory safe languages are radically safer than memory unsafe languages. The impact is blatantly demonstrated here.

When Heartbleed was a topic of discussion, some pointed out that Rust wouldn't have 100% protected from that vulnerability. So it is good to see some proof that using a safer language does in fact pay off in terms of fewer defects. I just wish there were some info around cost associated with development effort. Did the Rust code take longer to develop? If initial development was longer, what if we include time saved…

No post body was provided.

Re: Memory Safe Languages in Android 13

#499

Post by pjmlp »

tialaramex wrote: post #495
pjmlp wrote: post #456

Earlier quoted context omitted.

It does if you learn to use C# properly, https://learn.microsoft.com/en-us/dotnet/api/system.runtime.... In actual native code produced by RyuJit, you don't need to worry about cache lines for single instances, because the struct might not even exist at all, the Jit having mapped fields into CPU registers instead. When it matters, like the struct being part of an array, use StructLayout.

That link seems like it's about alignment rather than about arrays inside structures?

No, it is about alignment and packing, you use StructLayout attribute alongside LayoutKind and FieldOffsetAttribute.

https://learn.microsoft.com/en-us/dotnet/api/system.runtime....

You main issue was how structures arrange their fields.

Also regarding arrays and structs, as of C# 7 you can use fixed to declare static arrays inside structs, however these structs need to be marked as unsafe.

Re: Memory Safe Languages in Android 13

#500

Post by humanrebar »

tulio_ribeiro wrote: post #435
ghostwriter wrote: post #238

Earlier quoted context omitted.

> and argue that this means it's not worth the hassle of switching to a new language. Defenders of C++ argue that there's no reason to change the language, because new features around safety guarantees are being introduced into every C++ standard starting from C++11 at a remarkable pace, so remarkable that compilers implement them faster than the existing adoption rate. And the adoption rate speaks volumes about exis…

While new safety features in C++ may be impressive, Google's data shows that memory safety vulnerabilities are still a major issue. Switching to a memory-safe language like Rust can help reduce the risk of vulnerabilities and improve the overall security and reliability of a product. The potential benefits make it a worthwhile investment, even if it requires some effort to migrate from C++. #RustIsTheRealDeal

How much of the benefit comes from the rewrite itself? A more precise comparison would be rewriting that C or C++ in the same language but with memory safety in mind and see how things turned out.

The same question comes up when an existing system is rewritten from language A to language B and big performance gains are seen. The language could be the big cause, but so could the extra engineering effort itself -- updated design, fresh attention to the requirements, etc.

Post reply on HN