From owner-svn-src-user@FreeBSD.ORG Thu Aug 25 04:18:49 2011 Return-Path: Delivered-To: svn-src-user@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBDE1106564A; Thu, 25 Aug 2011 04:18:49 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE438FC0C; Thu, 25 Aug 2011 04:18:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id p7P4IlrM092899; Thu, 25 Aug 2011 08:18:47 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id p7P4IlNh092898; Thu, 25 Aug 2011 08:18:47 +0400 (MSK) (envelope-from ache) Date: Thu, 25 Aug 2011 08:18:47 +0400 From: Andrey Chernov To: Gabor Kovesdan Message-ID: <20110825041847.GA92789@vniz.net> Mail-Followup-To: Andrey Chernov , Gabor Kovesdan , src-committers@FreeBSD.ORG, svn-src-user@FreeBSD.ORG References: <201108222319.p7MNJKZ4072487@svn.freebsd.org> <20110823034416.GA7597@vniz.net> <4E5587CF.2010309@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5587CF.2010309@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: src-committers@FreeBSD.ORG, svn-src-user@FreeBSD.ORG Subject: Re: svn commit: r225093 - in user/gabor/tre-integration: contrib/tre/lib include X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 04:18:49 -0000 On Thu, Aug 25, 2011 at 01:22:55AM +0200, Gabor Kovesdan wrote: > This change was a semi-temporary solution. I'm wondering whether I > should remove the underscore and consider it a normal knob as it may be > useful outside TRE, however I cannot think of any concrete case. If it will be direct user-visible flag, you'll need to discuss that with TRE author first, but I don't see, why it needs to be normal flag. > What do you exactly mean by end of a word? I mean end of a word bits pool (opposite to start of it where all bit-occuped flags are grouped together). > Still, binary compatibility will > break if a new POSIX flag will be introduced because TRE already defines > some extra flags. POSIX often does not specify exact numeric values of its flags. If TRE author just add new flag, old binary still can run with new lib normally, since this place was not occuped previously. But if you separately use the same bit too, old binary can even run but produce strange results. > I'm not quite sure which is the best solution. If it is supposed to be direct user-visible flag, it should be coordinated with TRE author or moved to the end of bits pool at least to delay conflict as much as possible. If it is pure internal flag, it should not be in that field and in the public header at all. -- http://ache.vniz.net/