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.
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.
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.
10 comments
[ 3.5 ms ] story [ 36.2 ms ] threadi 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.
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.
Edit: actually llseek exists internally: https://www.man7.org/linux/man-pages/man3/lseek64.3.html
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
I understand it's not written for people like me, but here I am reading it
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.)
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.