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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Checked C

336 点作者 zmanian将近 9 年前

22 条评论

Animats将近 9 年前
This seems to be a successor to CCured from 2005, a project partially funded by Microsoft. [1]<p>The general idea is straightforward: <i>&quot;The unchecked C pointer type</i> * <i>is kept and three new checked pointer types are added: one for pointers that are never used in pointer arithmetic and do not need bounds checking (ptr), one for array pointer types that are involved in pointer arithmetic and need bounds checking (array ptr), and one for pointer types that carry their bounds with them dynamically (span).&quot;</i> So this is really a new language derived from C, to which programs can be converted.<p>This is basically a good idea, but it&#x27;s only useful if pushed hard by somebody like Microsoft. People won&#x27;t convert without heavy pressure.<p>[1] <a href="https:&#x2F;&#x2F;www.cs.virginia.edu&#x2F;~weimer&#x2F;p&#x2F;p477-necula.pdf" rel="nofollow">https:&#x2F;&#x2F;www.cs.virginia.edu&#x2F;~weimer&#x2F;p&#x2F;p477-necula.pdf</a>
评论 #11900244 未加载
评论 #11900366 未加载
评论 #11904469 未加载
评论 #11900304 未加载
Animats将近 9 年前
I had a go at this problem, backwards-compatible safe C, back in 2012.[1] It was discussed on the C standards mailing list, and the consensus was that it would work technically, but was politically infeasible. What I proposed was not too far from &quot;Checked C&quot;, but the syntax was different.<p>I&#x27;d defined a &quot;strict mode&quot; for C. The first step was to add C++ references to C. The second step was to make arrays first-class objects, instead of reducing them to pointers on every function call. When passing arrays around, you&#x27;d usually use references to arrays, which wouldn&#x27;t lose the size information as reduction to a pointer does.<p>Array size information for array function parameters was required, but could be computed from other parameters. For example, UNIX&#x2F;Linux &quot;read&quot; is usually defined as<p><pre><code> int read(int fd, char buf[], size_t len); </code></pre> The safe version would be<p><pre><code> int read(int fd, &amp;char buf[len], size_t len); </code></pre> In both cases, all that&#x27;s passed at run time is a pointer, but the compiler now knows that the size of the array is &quot;len&quot; and has something to check it against. The check can be made at both call and entry, and in many cases, can be optimized out. In general, in all the places in C where you&#x27;d describe an array with a pointer with empty brackets, as with &quot;buf[]&quot;, you&#x27;d now have to put in a size expression.<p>You could do pointer arithmetic, but only if the pointer had been initialized from an array, and was attached to that array for the life of the pointer.<p><pre><code> char s[100]; char* p = s; ... char ch = *p++; </code></pre> Because p is associated only with s, the compiler knows what to check it against.<p>There was more, but that&#x27;s the general idea. A key point was that the run-time representation didn&#x27;t change; there were no &quot;fat pointers&quot;. Thus, you could intermix strict and non-strict compilation units, and gradually convert a working program to strict mode.<p>This took less new syntax and fewer new keywords than &quot;Checked C&quot;. I was trying to keep C style, adding just enough that you could talk about arrays properly in C.<p>[1] <a href="http:&#x2F;&#x2F;www.animats.com&#x2F;papers&#x2F;languages&#x2F;safearraysforc43.pdf" rel="nofollow">http:&#x2F;&#x2F;www.animats.com&#x2F;papers&#x2F;languages&#x2F;safearraysforc43.pdf</a>
评论 #11904167 未加载
评论 #11904392 未加载
Keyframe将近 9 年前
You know, some people seem to scoff at replacement Cs. I&#x27;m kind of one of them. I know my reason(s) though. It&#x27;s not about other languages as much as C itself. I&#x27;ve been with it for awful long time now and I used to think I kind of know my way around it. I&#x27;ve changed that line of thinking, because I know it&#x27;s not true. I make a lot of mistakes, especially considering memory. At least (almost all of) my code isn&#x27;t public-facing.<p>Since I thought I knew C very well, I came to realisation (due to many memory bugs&#x2F;leaks) that maybe that&#x27;s not the case after all. What is it then? I can get performance out of it, lots of it (that&#x27;s one thing I know to do, somewhat at least). That&#x27;s when I questioned myself and started thinking that it&#x27;s not that I know C (I don&#x27;t, after 20 years or so), but that I am very comfortable with it and I don&#x27;t want to change that comfort. C++ and 90&#x27;s traumas and post 90&#x27;s (STL) traumas had a lot to do with it. Now, I&#x27;m fishing out for newer languages that would replace C for me, Rust namely, but I&#x27;m still falling back to C all the time. Now, I&#x27;m thinking that that&#x27;s just the way it is. I&#x27;m a C programmer and that&#x27;s how it will stay. At least for a long while. I do and have used a lot (A LOT) of languages in my past, but my core is always C (also first language I&#x27;ve learned). I don&#x27;t program anymore for a living (I do &quot;creative stuff&quot; in film and tv now), so that is now more prominent than any other time in the past. I do stuff for me only and I can pick and choose whatever I want to - yet, it&#x27;s always C.<p>Sorry for the &quot;rant&quot;.
评论 #11903288 未加载
评论 #11902863 未加载
rdtsc将近 9 年前
Interesting. I thought Microsoft has stopped liking C a while back. Remember complaining about C99 support in VS and getting a response about &quot;Just use C++ compiler as a C compiler, you don&#x27;t need C anymore&quot;. It took them until VS 2015 finally to support it.
评论 #11900396 未加载
评论 #11900562 未加载
评论 #11900778 未加载
评论 #11900915 未加载
kbart将近 9 年前
The idea is nice (although old and tried more than once), but I&#x27;m pessimistic as it doesn&#x27;t seem to be backwards compatible and requires a specific, new compiler. For legacy projects it&#x27;s hard&#x2F;impossible to change a toolchain&#x2F;compiler and for the new projects one can as well use Rust or other modern language.
partycoder将近 9 年前
Reminds me of Cyclone: <a href="https:&#x2F;&#x2F;cyclone.thelanguage.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cyclone.thelanguage.org&#x2F;</a><p>Many Cyclone ideas made it into Rust.<p>I strongly prefer Rust.
评论 #11900264 未加载
markokrajnc将近 9 年前
This clarifies the need for a more &quot;rust-like&quot; C. I hope something like this will flow into standard C...
评论 #11900827 未加载
评论 #11901017 未加载
baq将近 9 年前
the obvious question: how does this compare to rust? it looks like rust and this aim to solve a very similar set of issues in more or less similar way (&#x27;static and dynamic checking&#x27;). i&#x27;d be very interested in a table that compares capabilities of both. of course there&#x27;s a gigantic advantage of this being C, so in theory valid checked C would be valid C with all benefits of that.
评论 #11900390 未加载
评论 #11901489 未加载
ansgri将近 9 年前
<i>It is a design goal to allow Checked C to be a subset of C++ too.</i><p>Interesting. In times when many people advocate a safe C++ subset, Checked C grows the other way, adding C++-compatible notation to represent the most vital things like smart pointers.
eggy将近 9 年前
Good timing for me, since I have been falling back to C for some personal projects. I keep looking at Rust, but I just don&#x27;t have the time. It would be nice to leverage the experience I already have, and see what Checked C offers.
legulere将近 9 年前
This greatly lacks an overview as the specification[1] is very in-depth.<p>I kind of wonder if they&#x27;re working on automatic conversion tools between C and checked C. At least for ptr&lt;&gt; this should be trivial. If a function does no pointer arithmetic with a * pointer and only uses it in function calls that take ptr&lt;&gt;, can be converted to a function taking a ptr&lt;&gt;.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;checkedc&#x2F;releases&#x2F;download&#x2F;v0.5-final&#x2F;checkedc-v0.5.pdf" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;checkedc&#x2F;releases&#x2F;download&#x2F;v0.5...</a>
colejohnson66将近 9 年前
microsoft.com discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11900009" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11900009</a>
评论 #11900203 未加载
评论 #11900529 未加载
评论 #11900153 未加载
silent90将近 9 年前
Language extension for maintenance of legacy application sounds a little bullsh1t to me.<p>0) If the application needs checks on anything (at the cost of performance) then higher level language (like C++) should be chosen at design time. No use for new application. 1) Existing applications will NOT port directly. Real-life applications are tightly coupled with supported compiler(s), so the compiler would need the update. Errors&#x2F;exceptions (like overflows) would need handling and changes in logic. It could only deny read&#x2F;write from illegal area, but without the feedback. The speed is also a major thing. Boundary check could possible prevent some bugs, but the performance will drop dramatically (example: commonly used libs like OpenSSL).<p>One use case I see is to add an extension (like GCC&#x27;s for instance) for an existing compiler which does this. User could build a slower debug application and spot the silent errors during testing. An implementation thing, not the language extension.
fithisux将近 9 年前
I wish they supported namespaces.
评论 #11900628 未加载
fredmorcos将近 9 年前
So they couldn&#x27;t be bothered to contribute that directly back to LLVM&#x2F;Clang or am I missing something?
评论 #11901428 未加载
stuaxo将近 9 年前
Amazed at the amount of open source coming out of MS these days, very nice !
ArkyBeagle将近 9 年前
So databases and browsers are &quot;system software&quot; now?
vasilipupkin将近 9 年前
why? I mean if you think you really need checked C, then why not just use C++?
c3833174将近 9 年前
Does it include telemetry calls?
known将近 9 年前
<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Smart_pointer" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Smart_pointer</a>
EugeneOZ将近 9 年前
Microsoft style - be too closed to adopt existing solutions, always invent own ways&#x2F;standards.
vortico将近 9 年前
I&#x27;ve written lots of C and never had problems with buffer overruns, bounds checking, double frees, and other memory issues. Typically at a glance in one&#x27;s code, I can tell when behavior may be undefined, and once someone has a little experience, they can avoid undefined behavior altogether. Why does so much work go into fixing these problems? In other words, what are some examples of use cases of a stricter language like this, that would be too complicated for human eyes to quickly verify?
评论 #11900728 未加载
评论 #11900707 未加载
评论 #11900592 未加载
评论 #11900717 未加载
评论 #11900602 未加载
评论 #11900818 未加载