That is the point! A lot of system utilities **has** to know these sizes.
So far I have seen on this list a breakage in NFS, ncpfs, smbfs caused
by a mismatch in definitions between these two sets of headers and tons
of time wasted in heroic efforts to discover what is causing strange bugs
(with some voices pipin in "It works for me" but they have still previous
libraries/headers). I fully expect that if one would recompile ext2fs
with glibc then it will promptly break too. Probably we do not hear a
big outcry because most of people has tools still compiled with previous
headers and libraries. Add to this a nonchalant attitude of some folks,
who never seen 16-bit or 64-bit machine, towards freely swapping things
like 'int' and 'unsigned long' and we have a recipe for a disaster.
It smells to me that a lot of toubles which Red Hat had with a recent
release 5.0 for Alpha was caused exactly by that.
Even when things start to settle a bit it looks like in a future hitting
'make' with a new releas of Samba, say, will be an extremely risky
proposition. "This source is using gid_t. But wait, in this place this
has to be 'kernel gid_t' and few lines further this is 'glibc gid_t';
it is used in a library function call! Run away! 'kernel gid_t' was
just changed to a type 'foo' in the lastest kernel sources release!".
So why all these troubles? What this is exactly expect to buy us
for all current and future headaches?
Michal