From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 27 06:49:30 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFE65106564A for ; Fri, 27 Feb 2009 06:49:30 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 3BA748FC19 for ; Fri, 27 Feb 2009 06:49:30 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 27 Feb 2009 06:49:28 -0000 Received: from p54A3E7C3.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.231.195] by mail.gmx.net (mp062) with SMTP; 27 Feb 2009 07:49:28 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18YS6URN/MYm0jbqPeK7h8VvQk2ymJGQNZAInytdG TR3POBcTQHb/uY Message-ID: <49A78CF7.8090606@gmx.de> Date: Fri, 27 Feb 2009 07:49:27 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Christoph Mallon , Ed Schouten , hackers@FreeBSD.ORG References: <20090226180756.GX19161@hoeg.nl> <20090226204243.GA96251@zim.MIT.EDU> <49A70092.6030601@gmx.de> <20090226221403.GA96580@zim.MIT.EDU> <49A7171D.1060401@gmx.de> <20090227052821.GA98527@zim.MIT.EDU> In-Reply-To: <20090227052821.GA98527@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Cc: Subject: Re: Renaming all symbols in libmp(3) 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: Fri, 27 Feb 2009 06:49:31 -0000 David Schultz schrieb: > On Thu, Feb 26, 2009, Christoph Mallon wrote: >> David Schultz schrieb: >>> As for gcc's math builtins, most of them are buggy. They fail to >>> respect the dynamic rounding mode, fail to generate exceptions >>> where appropriate, fail to respect FENV_ACCESS and other pragmas, >>> etc. Also, the complex builtins use simplified formulas that don't >>> get the right answers for complex numbers with inf/nan components. >>> Try running some of the tests in tools/regression/lib/msun without >>> -fno-builtin and see what happens ;-) >> pow() is just an example. >> The compiler may do magic with any call which has semantics defined by >> the C standard in a hosted environment. > > Okay, so first, the world doesn't revolve around the strictest > possible interpretation of the C standard. For example, FreeBSD So you haven't seen enough crashes and security problems due to sloppy coding in the past decades, yet? I don't agree with everything the standard says (e.g. it tells you that it's a bad idea to call a function strange_quark()), but there's no reason not to avoid a simple name clash. > has an extension such that `printf("%s", NULL)' prints "(null)" > instead of having undefined behavior. But gcc translates this into This *is* perfectly valid undefined behaviour. > `puts(NULL)', which once again has undefined behavior. You can put And this is, too. I prefer the crash variant (or the one with the demons flying out of the programmers nose), because I've seen quite some programs which showed me "(null)" where they should have printed something sensible and bugs (sadly) only seem to have a real chance of being fixed in a timely manner, when they are hard crashes. A program limping along with invalid data is very bad and could be a security problem, too - imagine a "(null)" in an sprintf()ed path or something. > on your lawyer hat and counter that the beloved standard doesn't > guarantee that any such thing will work, but that's a very > contrarian attitude; the bottom line is that it's a POLA > violation, and the extension worked just fine for many years. It's a POLA violation in the first place, to have a function named pow(), which does not the "real" pow() thing. > Second, the problems with the math builtins I cited above violate > even a strict interpretation of the C standard. GCC is buggy, but that's a totally different story. > Third, this is a digression, and this is the last I'm going to say > about it. :-) Me, too.