From owner-cvs-all@FreeBSD.ORG Wed May 28 07:41:34 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C0CB1065672; Wed, 28 May 2008 07:41:34 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 35CA58FC23; Wed, 28 May 2008 07:41:33 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.40] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m4S7fKYV051961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 May 2008 00:41:22 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <483D0C9B.6000302@FreeBSD.org> Date: Wed, 28 May 2008 00:41:15 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: d@delphij.net, Xin LI , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, re@FreeBSD.org References: <200805272004.m4RK4SZt029194@repoman.freebsd.org> <483C7FF2.6000607@FreeBSD.org> <483C977F.20105@delphij.net> <20080528060333.GA4699@zim.MIT.EDU> In-Reply-To: <20080528060333.GA4699@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: cvs commit: src/include string.h src/lib/libc/string Makefile.inc memchr.3 memrchr.c src/sys/sys param.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 07:41:34 -0000 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