From owner-freebsd-stable@FreeBSD.ORG Fri Feb 1 04:22:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EFB86A4; Fri, 1 Feb 2013 04:22:45 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id E58378D9; Fri, 1 Feb 2013 04:22:44 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 712E956078; Thu, 31 Jan 2013 22:22:44 -0600 (CST) Date: Thu, 31 Jan 2013 22:22:44 -0600 From: Mark Linimon To: Brooks Davis Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 Message-ID: <20130201042244.GC20772@lonesome.com> References: <50F6D20A.6070306@FreeBSD.org> <20130117151502.GF29437@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130117151502.GF29437@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kimmo Paasiala , freebsd-stable@freebsd.org, Dimitry Andric X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 04:22:45 -0000 On Thu, Jan 17, 2013 at 09:15:02AM -0600, Brooks Davis wrote: > Not unless you consider adding new functions in a reserved namespace > (str*) to be ABI breakage. Well, what often happens is that when we add new functions, ports break. I think deciding whether this is or is not "ABI breakage" is semantics. The fact is that regressions get introduced with these types of changes. > The port should have continued to work unless it was recompiled so it > should have preferred it's own version of the strnvis symbol. If its > makefiles were properly constructed it would have failed to compile > due to the signature mismatch. The mantra should be "every possible combination of ways that a port's internal build glue can be wrong, is already included in the Ports Collection." In case after case we see fragile code that is written by people who are clearly not professionally trained. They "get it to work on their system" and then shove it out the door. Claiming that "they shouldn't do that" is correct but self-defeating. It's just the reality of open-source software. IMHO, the burden should be on whoever makes the change to find out whether or not regressions will be introduced. (And yes, I am very aware that we don't have -exp run capability right now, but this is one of the cases where I would like to suggest it would have helped.) mcl