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
