>> 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 HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
