Date: Wed, 28 May 2008 00:41:15 -0700 From: Maxim Sobolev <sobomax@FreeBSD.org> To: d@delphij.net, Xin LI <delphij@FreeBSD.org>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, re@FreeBSD.org Subject: Re: cvs commit: src/include string.h src/lib/libc/string Makefile.inc memchr.3 memrchr.c src/sys/sys param.h Message-ID: <483D0C9B.6000302@FreeBSD.org> In-Reply-To: <20080528060333.GA4699@zim.MIT.EDU> References: <200805272004.m4RK4SZt029194@repoman.freebsd.org> <483C7FF2.6000607@FreeBSD.org> <483C977F.20105@delphij.net> <20080528060333.GA4699@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote: > ISTR that in prior discussions on symbol versioning, the consensus > was that there's nothing wrong with adding new APIs in -STABLE > branches, but of course apps that use the new features won't be > backwards-compatible. > > By the way, one catch is that once you MFC symbols in the FBSD_1.1 > namespace, any new symbols in the same library need to go in > FBSD_1.2. We do guarantee that public namespaces do not change > across stable branches. This is important for API-checking tools > like appcert: even if you can't prevent problems like the one > described previously, at least you have some assurance as to which > versions of FreeBSD will run your app. Interesting. It's not very clear, though. Are you saying that in this case memrchr will be in different namespace than the rest of 6.4 libc functions? -Maxim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?483D0C9B.6000302>