On Mon, 12 Feb 2001, Mike Smith wrote:
> > > Then wouldn't the "partially applied patch" rule apply?  eg, back it
> > > out until the issues can be resolved.  Breaking the upgrade path isn't
> > > acceptible.
> > 
> > If you bump the library versions, doesn't that fix the upgrade
> > path?
> No, because the library version bump has already happened.

It was suggested we bump it again.

> > I can think of a gross hack that gets around the problem for
> > now.  Allocate the FILE with enough storage for the lock, but
> > don't declare it in FILE.  __sF[3] would still be the same
> > size and we could have __sF_locks[3] internally, and use these
> > if fp is stdin, stdout, or stderr, else the lock is at the end
> > of the struct.
> You can do better than this.  Put the lock in FILE, and define a new 
> structure FILE_old, which has the same size/layout as the old FILE 
> structure.
> Now, __sF is defined as an array of FILE_old and handled specially 
> internally (this part is gross, but necessary).  You'll have to put the 
> lock, etc. in a separate array and handle it specially, or you can have 
> real FILE structures shadowing the FILE_old structures.

This is exactly what I was suggesting above, except I wasn't going
to publicize the "new" FILE, just use it internally where it was
needed (findfp.c, _flock_stub.c, etc).

> Because this is a hack for binary compatibility and upgrading only, you 
> can throw it away before we actually get to 5.0.

Dan Eischen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to