From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 15:11:42 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E156216A468 for ; Sun, 20 May 2007 15:11:42 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id 416BD13C447 for ; Sun, 20 May 2007 15:11:41 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id E60C6E7A3F9 for ; Sun, 20 May 2007 15:11:38 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id 379DA7E92; Sun, 20 May 2007 17:11:26 +0200 (CEST) Date: Sun, 20 May 2007 17:11:25 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20070520151125.GA8244@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20070520023127.5101cc4a@kan.dnsalias.net> <86k5v3h6zm.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86k5v3h6zm.fsf@dwp.des.no> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: HEADS UP: OpenSSL problems after GCC 4.2 upgrade X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2007 15:11:43 -0000 On Sun, May 20, 2007 at 05:03:57PM +0200, Dag-Erling Smørgrav wrote: > Alexander Kabaev writes: > > there were several reports of OpenSSL being broken when compiled with > > GCC 4.2. It turns out OpenSSL uses function casting feature that was > > aggressively de-supported by GCC 4.2 and GCC goes as far as inserting > > invalid instructions ON PURPOSE to discourage the practice. > > Is there a web page somewhere (or an archived mailing list discussion, > or whatever) which discusses the issue and explains the rationale for > intentionally generating incorrect code? It happened in the past, e.g. with va_arg. In that case gcc creates explicit abort() calls, because it can't refuse the code (syntactically correct C), but the runtime behaviour is completely implementation defined. Joerg