Re: HEADS-UP new statfs structure

Robert Watson wrote:
> What's going on is the following: while we have a compatibility system
> call in place, it only affects applications linked against non-current
> libc.  As soon as you recompile libc, applications expecting the old
> statfs() ABI get the new statfs(), and depending on where their smaller
> struct statfs is located, may stomp on memory they're using for something
> else (like critical data structures).  This means that any application
> using statfs() and linked against libc.so.5 may start having problems.
> Not only that, but as you begin to compile new programs, they start
> expecting the new statfs() API, so if you keep the old libc, they'll start
> expecting to see extended struct statfs information in a structure that's
> too small.  This is almost certainly a less harmful failure mode than the
> former.  However, it turns out statfs() is used in a fair number of
> applications (and libraries)...

I recently ran into a similar need to break the API without
breaking the ABI.  The easiest way to do this is to add a new
system call, with a different name, and scope the changeover
to compile time.

At some later point, when you bump the libc version, you can
change the name to the new name, and deprecate the old.  For
the "statfs" case, here's the example:

% nm /usr/lib/libc.a | grep "T _statfs"
00000008 T _statfs
00000008 T _statfs_new

% grep statfs /usr/include/sys/mount.h
#define statfs statfs_new
int     statfs(const char *, struct statfs *);

Viola!  Recompile, get the new, don't recompile, get the old.

The only place this breaks is sucky programs that define the structure
without including the header file to get the prototype and #define in
scope as well.

-- Terry