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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Going long long on time_t

130 点作者 hebz0rl超过 11 年前

11 条评论

throwaway_yy2Di超过 11 年前
If anyone has trouble reading this, there&#x27;s also plain text versions of individual slides:<p><a href="http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp00002.txt" rel="nofollow">http:&#x2F;&#x2F;www.openbsd.org&#x2F;papers&#x2F;eurobsdcon_2013_time_t&#x2F;mgp0000...</a><p><a href="http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp00003.txt" rel="nofollow">http:&#x2F;&#x2F;www.openbsd.org&#x2F;papers&#x2F;eurobsdcon_2013_time_t&#x2F;mgp0000...</a><p>etc.<p>Here&#x27;s the whole thing in one page, minus images:<p><a href="https://gist.github.com/anonymous/6757266/raw/3469464cb802e7c9a6cbe7c2508b252f7ad8ebdd/Theo+de+Raadt%3A+Going+long+long+on+time_t+to+cope+with+2%2C147%2C483%2C647%2B1" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;anonymous&#x2F;6757266&#x2F;raw&#x2F;3469464cb802e7...</a>
评论 #6466800 未加载
gizzlon超过 11 年前
Good read, even if you, like me, don&#x27;t care too much about the low-level stuff..<p>A few takeaways:<p>- Embedded 32bit is everywhere. Sure they&#x27;ll fix the obvious ones, but I&#x27;m sure some things will be forgotten about. This problem might not be taken seriously after the Y2K debacle.<p>- The OpenBSD guys &amp; gals like to do implement new designs and ideas. Sometimes radical. (but I already knew that)<p>- A transitional solution can end up being <i>the</i> solution ans stick around forever :(<p>- Theorem &quot;In operating systems, increased popularity leads to greater resistance to change&quot;. Probably true in most &quot;products&quot;.
评论 #6471166 未加载
评论 #6470526 未加载
Peaker超过 11 年前
For format strings, why not do the inttypes.h thing, and define a macro for the format specifier of (time_t)?<p><pre><code> &quot;%&quot; PRI_TIME_T</code></pre>
评论 #6467062 未加载
评论 #6467932 未加载
cbsmith超过 11 年前
So, this slide confused&#x2F;troubled me: <a href="http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp00029.html" rel="nofollow">http:&#x2F;&#x2F;www.openbsd.org&#x2F;papers&#x2F;eurobsdcon_2013_time_t&#x2F;mgp0002...</a><p>I don&#x27;t see why it would be a good idea to convert &quot;time_t&quot; to &quot;long long&quot;. Having an alias specifically for time_t is part of what makes this kind of work doable. I could see maybe introducing another alias like &quot;time64_t&quot; or something, but once you convert it to &quot;long long&quot; the type is no longer tagged in a way that makes it easy to find and more importantly suggests to the programmer they ought to NOT make assumptions about its size. Heck, in a perfect world I&#x27;d either introduce a new % symbol specifically for time_t width or have a macro that expands to represent its width (not to mention make it mandatory to use compiler warnings about string formats not matching argument widths).<p>I also found the comment about &quot;would love better compiler tools -- none found so far&quot;. Certainly there are things like Sparse (<a href="https://sparse.wiki.kernel.org/index.php/Main_Page" rel="nofollow">https:&#x2F;&#x2F;sparse.wiki.kernel.org&#x2F;index.php&#x2F;Main_Page</a>) which correctness verification easier.
评论 #6467035 未加载
评论 #6468679 未加载
评论 #6467049 未加载
pjbringer超过 11 年前
I notice the ideas that it is not the number of contributors that matter, but the number of sufficiently skilled ones, and the that popularity impedes change. I can&#x27;t help draw a parallel with the advice that you should listen to your most valuable customers, and potential customers, and that the rest of your users will expect free stuff, and complain loudly when you pivot.
liveoneggs超过 11 年前
NetBSD did this a while ago, but was better about binary compatibility and things.<p><a href="http://www.netbsd.org/changes/changes-6.0.html#time_t" rel="nofollow">http:&#x2F;&#x2F;www.netbsd.org&#x2F;changes&#x2F;changes-6.0.html#time_t</a>
alextingle超过 11 年前
Any idea why they would use long long rather than int64_t?
评论 #6467081 未加载
评论 #6467056 未加载
评论 #6466886 未加载
eliteraspberrie超过 11 年前
The C standard only states that time_t is an integer (or floating-point) type, and POSIX further states it represents seconds since the epoch, so a 64-bit time_t is a good solution.<p>In order to find and change occurrences of time_t in ports more easily, they could use the Coccinelle tool.[1] The following semantic patch would find and replace variable declarations of type time_t:<p><pre><code> @sys_types@ @@ #include &lt;sys&#x2F;types.h&gt; @time_t depends on sys_types@ identifier x; @@ - time_t x + long long int x ; </code></pre> Replacing printf format specifiers is more difficult, so the following semantic patch will find printf statements which use time_t variables, which can then be edited manually:<p><pre><code> @sys_types@ @@ #include &lt;sys&#x2F;types.h&gt; @stdio@ @@ #include &lt;stdio.h&gt; @printf depends on sys_types &amp;&amp; stdio@ identifier x; @@ time_t x; ... * printf(..., x, ...); </code></pre> These can be used as follows:<p><pre><code> $ spatch --sp-file foo.cocci --dir &#x2F;path&#x2F;to&#x2F;ports </code></pre> where `foo.cocci` is the name of one of the semantic patches above.<p>[1] <a href="http://coccinelle.lip6.fr/" rel="nofollow">http:&#x2F;&#x2F;coccinelle.lip6.fr&#x2F;</a>
meshko超过 11 年前
Funny they don&#x27;t mention that starting Visual Studio 2005 time_t is 64bit on 32bit builds.
评论 #6469680 未加载
snoonan超过 11 年前
It&#x27;s going to be a long long time_t.<p>(sorry.)
dllthomas超过 11 年前
... and I think it&#x27;s gonna be a long long time.