From owner-svn-src-all@FreeBSD.ORG Mon Nov 8 15:37:15 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63E96106566C; Mon, 8 Nov 2010 15:37:15 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 308908FC1D; Mon, 8 Nov 2010 15:37:14 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 816C511B850; Mon, 8 Nov 2010 09:37:14 -0600 (CST) Received: from 192.168.1.70 (bl17-210-129.dsl.telepac.pt [188.82.210.129]) by lavabit.com with ESMTP id YNFCF895O5B0; Mon, 08 Nov 2010 09:37:14 -0600 References: <201011081331.oA8DViNq033723@svn.freebsd.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Mon, 8 Nov 2010 15:37:10 +0000 To: Hajimu UMEMOTO X-Mailer: Apple Mail (2.1081) Cc: svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, svn-src-stable-8@FreeBSD.org Subject: Re: svn commit: r214984 - stable/8/lib/libproc X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 15:37:15 -0000 On Nov 8, 2010, at 3:19 PM, Hajimu UMEMOTO wrote: > Hi, >=20 >>>>>> On Mon, 8 Nov 2010 15:06:12 +0000 >>>>>> Rui Paulo said: >=20 > rpaulo> It's on my plans, but basename_r is not POSIX and there was a = private discussion about it a couple of weeks ago. The conclusion is = that we should adopt the Android semantics of basename_r(). >=20 > I found the thread, and understood it. However, I still wonderling if > breaking thread-safeness in proc_sym.c is okay, though it may not be > necessary. We can live with it for now while I work on a new basename_r(). Regards, -- Rui Paulo