Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!ucsfcgl!pixar!rta
From: rta@pixar.UUCP (Rick Ace)
Newsgroups: comp.unix.wizards
Subject: changing "stat" (was Re: Why Partition a Hard Disk)
Summary: old .o files can get the new stat() and lose big
Message-ID: <2381@pixar.UUCP>
Date: 3 Sep 88 19:19:06 GMT
References: <4360004@wdl1.UUCP> <1988Aug31.174144.1694@utzoo.uucp> <8424@smoke.ARPA>
Organization: Pixar -- Marin County, California
Lines: 27

In article <8424@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes:
# In article <66800@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
# >Yes, changing the "stat" structure may be painful.  Not changing it may be
# >painful as well....
# 
# A reasonable way to make the change is to introduce a new system call,
# which acts the way one wants (e.g. long st_ino), change the C library
# stat() interface to use the new system call (and change the stat.h
# header at the same time!), then recompile and test all the system
# software at one's leisure.  Old binaries keep working until one is
# finished checking everything out and removes the old system call (if
# ever; usually it is left enabled so customers don't have to recompile
# anything).  Old binaries can fail on long inode numbers, but this is
# no worse than not making the change, and at least the official system
# software has been upgraded to work right.

If you try this, be sure to BLOW AWAY AND RECOMPILE all old .o files,
because they expect to get the old stat structure back, and if you link
them up with the new stat() in libc.a, they will get something other
than what they are expecting; if the new struct stat is larger than
the old one, memory following the structure will be mysteriously
trashed, most likely leading to lots of head-scratching.

Rick Ace
Pixar
3240 Kerner Blvd, San Rafael CA 94901
...!{sun,ucbvax}!pixar!rta