This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ PATCH] Don't clear DECL_BUILT_IN_CLASS/DECL_FUNCTION_CODE when redeclaring a builtin if types match

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
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]