TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

It is time to standardize principles and practices for software memory safety

76 点作者 mepian3 个月前

7 条评论

flitzofolov3 个月前
Makes sense, good luck! I know that sounds snarky, I'm looking forward to rational progress and cooperation on the evolution and adoption of the standard. Just haven't seen that played out in such a planned orderly fashion yet (ipv6?).
评论 #42971382 未加载
评论 #42969751 未加载
User233 个月前
One of the most under appreciated things about the JVM is its well-defined memory model.
评论 #42970596 未加载
评论 #42970827 未加载
mimd3 个月前
I know this article is more a buisness case presentation than a full demonstration of the field but the TR also misses some points.<p>Why remove the refrences in the TR to frama-C, cbmc, etc. from the opinion report? They are easier to adopt than the heavier tooling of coq, etc. I&#x27;m always suprised to see those tools ignored or downplayed, when it comes to these discussions. I do agree with the TR&#x27;s sentiment that we need to improve accessibility and understanding of these tools, but this is not a great showing for that sentiment.<p>Additionally, both articles miss that compiler modified languages&#x2F;builds are a path, such as fbounds-safety. They will be part of the solution, and frankly, likely the <i>biggest</i> part at the rate we are going. Eg. current stack defenses for C&#x2F;C++&#x2F;Rust, unaddressed in safe language design, are compiler based. The compiler extension path is not particularly different than cheri, which requires a recompile with some modifications, and the goal of both approaches is to allow maintainers to band aid dependencies with minimal effort.<p>The TR handwaves away the question of the complexity of the development of formal method tools for Rust&#x2F;Unsafe Rust and C++. Ie. rust really only has two tools at the moment: miri and kani (which is a cbmc wrapper). Heavier tools are in various states of atrophying&#x2F;development. And C++ support from the c family of formal tools such as frama-C, is mostly experimental. It&#x27;s not assured, that with the continued language development rate of both languages and the complexity of the analysis, that the tools for these languages will come forth to cover this gap anytime soon.<p>I do not think the claim in the TR that the current unsafe&#x2F;safe seperation will result in only requiring formal analysis of the unsafe sections is true, as logical errors, which are normal in safe rust, can cross the boundries to unsafe and cause errors, thus nessecitating whole program analysis to resolve if an unsafe section could result in errors. Perhaps it will decrease the constants, but not the complexity. If rust does further restricts perhaps more of the space could be covered to help create that senario, but the costs might be high in both usability and so on.
SOLAR_FIELDS3 个月前
Is it a hot take to believe that no humans are infallible and that only languages with memory safe guarantees can offer the kind of safety the author seeks? With the advent of rust, c and c++ programmers can no longer argue that the performance tradeoff is worth giving up safety.<p>There are, of course, other good reasons to choose c and c++ over rust. And of course rust has its own warts. just pointing out that performance and memory safety are not necessarily mutually exclusive
评论 #42969929 未加载
评论 #42970446 未加载
deadliftdouche3 个月前
<a href="https:&#x2F;&#x2F;github.com&#x2F;Speykious&#x2F;cve-rs">https:&#x2F;&#x2F;github.com&#x2F;Speykious&#x2F;cve-rs</a>
评论 #42970121 未加载
userbinator3 个月前
It&#x27;s time to stop jailbreaking&#x2F;rooting, fully take control away from the user and enforce DRM more strongly?
评论 #42970268 未加载
评论 #42970179 未加载
评论 #42970426 未加载
评论 #42970454 未加载
kojolina3 个月前
Just bang out a bunch of C code, feed it to an AI: &quot;Make this memory safe&quot;. Profit.<p>No need for rust, Ada, CHERI, SPARK, etc.
评论 #42970979 未加载
评论 #42970811 未加载
评论 #42970497 未加载