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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Some __nonstring__ Turbulence

136 点作者 jwilk19 天前

8 条评论

AceJohnny219 天前
Fedora stupidly uses beta compiler in new release, Torvalds blindly upgrades, makes breaking, unreviewed changes in kernel, then flames the maintainer who was working on cleanly updating the kernel for the not-yet-released compiler?<p>I admire Kees Cook&#x27;s patience.
评论 #43791760 未加载
评论 #43791492 未加载
评论 #43791636 未加载
评论 #43791603 未加载
jaapz19 天前
Torvalds is known for being flamey towards kernel maintainers, but most of the time that is for good reason. Here however, he should just admit he made a mistake instead of doubling down. Admitting your own mistakes is a mark of a great maintainer as well.
评论 #43791800 未加载
评论 #43793491 未加载
评论 #43801820 未加载
Ukv19 天前
From the comments:<p>&gt; C &quot;strings&quot; work the way they do because C is a low level language, where you want to be able to do low-level things when necessary. It&#x27;s a feature, not a deficiency.<p>Are NUL-terminated strings really considered preferable, even for low-level work? I always just considered them an unfortunate design choice C was stuck with.<p>Many O(1) operations&#x2F;checks become O(n) because you have to linearly traverse the entire string (or keep a second pointer) to know where it ends&#x2F;how long it is; you can&#x27;t take a substring within another string without reallocating and copying that part over with a new NUL appended at the end; you can&#x27;t store data that may contain a NUL (which text <i>shouldn&#x27;t</i>, in theory, but then you need a separate approach for binary data); and plenty of security issues arise from missing or extra NULs.
评论 #43792100 未加载
评论 #43793493 未加载
评论 #43793019 未加载
评论 #43793599 未加载
Philpax19 天前
Linus was a hypocritical asshole here, but more to the point, why are they using strings for this anyway? No byte arrays &#x2F; literals in their C dialect?
评论 #43793102 未加载
jey19 天前
That the annotation applies to variables and not types is surely an oversight or mistake right? Seems like it could have been easier to initially implement that way but it just doesn’t seem to fit with how C type system works. (Yes it will make declarations uglier to do it on types but that ship has sailed long ago; see cdecl.org)
评论 #43791274 未加载
评论 #43792258 未加载
评论 #43791238 未加载
评论 #43792974 未加载
mastax19 天前
It’s still shocking to me that there’s no official kernel CI.
评论 #43800644 未加载
Incipient19 天前
This is definitely unexpected for me - I&#x27;d have thought something like an RC for a kernel would have to be &#x27;approved&#x27; for release only after passing all tests, which should include building with all official compilers (and all official architectures, etc).<p>Unless either the older GCC or the beta GCC isn&#x27;t &quot;official&quot;? In which case that&#x27;s not necessarily expected to be picked up in an RC?
评论 #43794102 未加载
评论 #43792677 未加载
bjourne19 天前
Err... we teach C neophytes that you should never write values to variables that are larger than what the variables can hold. Don&#x27;t write an int to a short, don&#x27;t write a short to a char, and don&#x27;t initialize five bytes to an array storing four bytes. Am I missing something here? char foo[4] = &quot;ABCD&quot; is always incorrect, no ifs and buts. If you want &quot;readable&quot; bytes, use character literals. You should never discount the null terminator.
评论 #43793621 未加载