I always thought the purpose of abstract types like ino_t and off_t was
to provide a type whose length could vary between systems and over time
without needing application code rewrites, just a recompile.
By making d_ino long, aren't we shooting ourselves in the foot for when
we're running on systems with millions of terabytes of disk and need
shitloads of inodes? Yes, by that time we will probably have 128 or 256
bit longs, but we shouldn't be relying on that fact.
I know just how ridiculous it seems to ever want that many inodes, but
just think how big your hard drive was 10 years ago (if you had one at
all -- mine was 10MB). I expect Linux to still be around in another 10
years, and I expect similar or greater increases in storage capacities
(and decreases in physical size!).
Remember, Bill Gates once said he couldn't see why anyone would ever
need more than 640K RAM. How stupid does that sound now?
Also, surely __kernel_off_t is an internal kernel type, and shouldn't
be being used by userland applications. Abstracting this to off_t would
also promote portability between Linux and other versions of Unix.
Tet
PS. Does anyone what what (if anything) POSIX and/or the SUS have to say
about this?
-- ``Anyone who cannot cope with mathematics is not fully human. He is at best a tolerable subhuman who has learned to wear shoes, bathe and not make messes in the house.'' -- from the notebooks of Lazarus Long --------------------+--------------+---------------------------------------- tethys@ml.com | Micro$oft: | Linux, the choice of a GNU generation. tet@astradyne.co.uk | Just say no! | See http://www.uk.linux.org for details