Why Unix's lseek() has that name instead of seek() | Hacker News Reader

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

utcc.utoronto.ca

43 pointsadunk10 comments

I wish the article did more to explain why "the naming for fstat/lstat not consistent with fseek/lseek".

I understand it's not written for people like me, but here I am reading it

That's mostly explained in Zack Weinberg's Fediverse post/answer: https://hackers.town/@zwol/111684752785283333

The one open thing is why BSD picked 'l' for lstat() to mean symbolic links (unless someone has asked one of the BSD people that). Possibly it's just because 'sstat()' would look weird.

(I'm the author of the linked-to entry.)

spoiler: the `l` is for long. the previous `seek()` took an int.

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.

I am curious why you yourself have "blurted out the answer" if you enjoyed the opposite from the article? This isn't a callout or anything, I'm just genuinely curious.

well i prefaced it with "spoiler". i probably could have made a stronger warning.

it's useful in general in a forum like this, for people that just want the answer. like when a news or blog article has a question in the headline to make you wade through the ads to get to the main point. not too different to how it's useful when people post a paywall bypass link. sure, anyone can just figure that on their own, but it's useful to simply have a link right here on HN, or a summary or abstract of an article.

so that was my thinking. that the very large majority don't care and would benefit from just having the answer.

i tried to encourage reading the blog anyway, even after knowing the answer. you know what, let me edit the answer out. i think you're right. if you don't care you don't care so why ruin the article. damn. too late to edit.

And then it became lseek64(), when longs weren't no longer big enough.

So llseek would have been logical. But maybe being informative and portable is better.

Edit: actually llseek exists internally: https://www.man7.org/linux/man-pages/man3/lseek64.3.html

On Linux.

"the utoronto unix blog in general is enjoyable"

Didn't know it was called the utoronto unix blog. I've always called it CSpace like the author calls it here: https://utcc.utoronto.ca/~cks/space/FrontPage

Even back then the unix abstractions were breaking down.

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?

These little problems exist everywhere in the bowels of stuff, and they're sort of fun design problems to think about.

And the problem is that these were small machines, where everything counts. There was no point wasting some bytes and cycles with typeof metadata.

Reply on news.ycombinator.com