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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Why Unix's lseek() has that name instead of seek()

43 点作者 adunk超过 1 年前

3 条评论

mkoryak超过 1 年前
I wish the article did more to explain why &quot;the naming for fstat&#x2F;lstat not consistent with fseek&#x2F;lseek&quot;.<p>I understand it&#x27;s not written for people like me, but here I am reading it
评论 #38870462 未加载
jiveturkey超过 1 年前
spoiler: the `l` is for long. the previous `seek()` took an int.<p>i rather enjoy the exposition of the article. he weaved the story nicely rather than just blurt out the answer. the utoronto unix blog in general is enjoyable.
评论 #38870911 未加载
评论 #38873089 未加载
评论 #38872456 未加载
mannyv超过 1 年前
Even back then the unix abstractions were breaking down.<p>The problem with lseek is pretty simple: how do you know if a file size is bigger than your int? You can do a stat, but that means stat should return a long, but if all you have are ints then what do you do? Make a signed negative value an offset off of the end of an int?<p>These little problems exist everywhere in the bowels of stuff, and they&#x27;re sort of fun design problems to think about.<p>And the problem is that these were small machines, where everything counts. There was no point wasting some bytes and cycles with typeof metadata.