> > 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.
> 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.
Because this is a hack for binary compatibility and upgrading only, you
can throw it away before we actually get to 5.0.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
