cvs commit: src/include string.h src/lib/libc/string Makefile.inc memchr.3 memrchr.c src/sys/sys param.h

[David Schultz]

On Wed, May 28, 2008, Daniel Eischen wrote:
> On Wed, 28 May 2008, David Schultz wrote:
> 
> >On Wed, May 28, 2008, Daniel Eischen wrote:
> >>No, all new symbols in 8-current go into FBSD_1.1, not 1.2.  The
> >>only time we go to 1.2 is when 8.x branches to 9.0.  If for some
> >>reason memrchr() were to change its ABI, then we would go to 1.1.1
> >>in -current for the ABI change and any subsequent new symbols, and
> >>the MFC to 7.x would also be 1.1.1.
> >>
> >>It is ok for a FBSD_1.1 in -current to be a superset of FBSD_1.1
> >>in a previous branch.  In fact you can't prevent them from being
> >>different unless you mandate that all new symbols get MFC'd to
> >>their respective namespaces in previous branches.
> >
> >Perhaps I misinterpreted what you said about this last year, but I
> >thought you said you didn't want symbols added to existing
> >namespaces in -STABLE. In 7.X, why would it be okay to add new
> >symbols to FBSD_1.1 between releases but not to FBSD_1.0?
> 
> I think you're just off by a version.  -stable didn't have
> FBSD_1.1, so we just _did_ add memrchr() to a _new_ namespace
> in -stable.

Yes, yes, that's fine, that's what I said. But you also said it's
fine to add things to FBSD_1.1 in 7.X, which I think is different
from what you told me last year...

In practice, this means that if a binary uses FBSD_1.0 and
FBSD_1.1 symbols, the only thing you can say with confidence is
that it will run in 8.0-RELEASE. That's fine with me; I'd just
like to make sure I understand what you do and don't intend to
guarantee.