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