public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mark Mitchell <mark@codesourcery.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Jason Merrill <jason@redhat.com>,
	Alexandre Oliva <aoliva@redhat.com>,
	  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
Date: Sun, 07 Oct 2007 17:43:00 -0000	[thread overview]
Message-ID: <47091AAA.4000605@codesourcery.com> (raw)
In-Reply-To: <20071002114954.GC2625@devserv.devel.redhat.com>

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

  reply	other threads:[~2007-10-07 17:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-02 11:51 Jakub Jelinek
2007-10-07 17:43 ` Mark Mitchell [this message]
2007-10-07 19:12   ` Jakub Jelinek
2007-10-07 20:06     ` Mark Mitchell
2007-10-09 19:17       ` Jason Merrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47091AAA.4000605@codesourcery.com \
    --to=mark@codesourcery.com \
    --cc=aoliva@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jason@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).