From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19097 invoked by alias); 7 Oct 2007 17:43:24 -0000 Received: (qmail 19089 invoked by uid 22791); 7 Oct 2007 17:43:24 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 07 Oct 2007 17:43:16 +0000 Received: (qmail 12613 invoked from network); 7 Oct 2007 17:43:13 -0000 Received: from unknown (HELO ?192.168.0.3?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Oct 2007 17:43:13 -0000 Message-ID: <47091AAA.4000605@codesourcery.com> Date: Sun, 07 Oct 2007 17:43:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jakub Jelinek CC: Jason Merrill , Alexandre Oliva , gcc-patches@gcc.gnu.org Subject: Re: [C++ PATCH] Don't clear DECL_BUILT_IN_CLASS/DECL_FUNCTION_CODE when redeclaring a builtin if types match References: <20071002114954.GC2625@devserv.devel.redhat.com> In-Reply-To: <20071002114954.GC2625@devserv.devel.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg00367.txt.bz2 Jakub Jelinek wrote: > The C FE always keeps DECL_BUILT_IN_CLASS when types match, even when > newdecl defines a function. > But the C++ FE doesn't do this: > if (new_defines_function) The standard does prohibit redefining these functions. But, in practice, people would be surprised if they did this: /* Nobody should use memcpy, I think it's evil! */ extern "C" void memcpy (void *, void *, size_t) { abort (); } void f() { memcpy (...); } and the program did not abort because the call to memcpy was inlined. Or, for a more practical example, if the implementation of memcpy had additional auditing code -- as the GLIBC headers are trying to do. So, I think the C++ front-end behavior is reasonable: if you define memcpy, we forget what we think we know about memcpy, and just treat it as we would any other function. At least in the example you posted, it looks like the GLIBC code is checking for something that is known at compile-time: whether the arguments to snprintf are inherently wrong. Why can't we handle that with a compiler warning/error so that this check benefits all users on all operating systems, regardless of C library? You can't use that approach for functions that GCC doesn't know about -- but, then again, you won't have the performance problem that you're concerned about in that case either. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713