Re: Issues with lseek(2) on a block device

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> It looks to me like "we didn't bother making it do anything in
>> particular, so you get whatever it happens to give you".
> "bug" ultimately means "failure to conform to expectations".

Well...maybe.  Depends on whose expectations.  If I expect, say, that
typing a tab on a command line puts a tab into the command, and someone
else expects it to do filename completion, which one is the bug?

Usually, I use "bug" to mean something close to what you said, where
the answer to "whose" is "the author's".

> We could debate what expectations might be for stat and block device
> sizes, but it is definitely against expectations that something so
> simple as retrieving the size of a storage device has such a messy
> interface.

Again, whose expectations?

My expectations, formed from decades of experience, are that it _is_ a
messy thing.

At least one person clearly expected that lseek would do the trick.
(Interestingly, I would not have even considered lseek; if I'd had to
pick a stock call that I would expect to return the size of a disk, it
would be stat() or one of its variants - lstat, fstat, etc.)

>> My own method of finding disk device size is [...].  I'd expect it
>> to be highly portable.  The only cases I'd expect it to fail in are
>> disks over 4G (or perhaps 2G) on systems with only 32 bits for
>> off_t.

> ...or tapes.

Or ttys.

Tapes don't really have a size in that sense to obtain.  (Most tapes.
Some DEC tapes do look a lot disks with sec/trk and trk/cyl both 1 and
what for disks would be _extremely_ long seek times.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B