[HN Gopher] Why Unix's lseek() has that name instead of seek()
       ___________________________________________________________________
        
       Why Unix's lseek() has that name instead of seek()
        
       Author : adunk
       Score  : 39 points
       Date   : 2024-01-04 09:38 UTC (13 hours ago)
        
 (HTM) web link (utcc.utoronto.ca)
 (TXT) w3m dump (utcc.utoronto.ca)
        
       | jiveturkey wrote:
       | 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.
        
         | n6h6 wrote:
         | 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.
        
           | jiveturkey wrote:
           | 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.
        
         | pjmlp wrote:
         | And then it became lseek64(), when longs weren't no longer big
         | enough.
        
         | maxparay wrote:
         | "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
        
       | mkoryak wrote:
       | 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
        
         | thatcks wrote:
         | 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.)
        
       | mannyv wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-01-04 23:02 UTC)