[PATCH] c/66516 - missing diagnostic on taking the address of a builtin function
Marek Polacek
polacek@redhat.com
Mon Jun 22 14:41:00 GMT 2015
On Sun, Jun 21, 2015 at 05:05:14PM -0600, Martin Sebor wrote:
> Attached is a patch to reject C and C++ constructs that result
> in obtaining a pointer (or a reference in C++) to a builtin
> function. These constructs are currently silently accepted by
> GCC and, in most cases(*), result in a linker error. The patch
> brings GCC on par with Clang by rejecting all such constructs.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
It seems like this patch regresess pr59630.c testcase; I don't see
the testcase being addressed in this patch.
> 2015-06-21 Martin Sebor <msebor@redhat.com>
>
> PR c/66516
> * c/c-typeck.c (default_function_array_conversion): Reject
> converting a builtin function to a pointer.
> (parser_build_unary_op): Reject taking the address of a builtin
> function.
> * cp/call.c (convert_like_real): Reject converting a builtin function
> to a pointer.
> (initialize_reference): Reject initializing a reference with a builtin
> function.
> * cp/typeck.c (cp_build_addr_expr_strict): Reject taking the address
> of a builtin function.
> (build_reinterpret_cast_1): Reject casting a builtin function to
> a pointer.
> (convert_for_initialization): Reject initializing a pointer with
> the a builtin function.
Please no c/ and cp/ prefixes.
> +#include <stdlib.h>
As Joseph already pointed out, this is redundant.
> @@ -3384,7 +3392,14 @@ parser_build_unary_op (location_t loc, enum tree_code code, struct c_expr arg)
> result.original_code = code;
> result.original_type = NULL;
>
> - if (TREE_OVERFLOW_P (result.value) && !TREE_OVERFLOW_P (arg.value))
> + if (code == ADDR_EXPR
> + && TREE_CODE (TREE_TYPE (arg.value)) == FUNCTION_TYPE
> + && DECL_IS_BUILTIN (arg.value))
> + {
> + error_at (loc, "taking address of a builtin function");
> + result.value = error_mark_node;
> + }
> + else if (TREE_OVERFLOW_P (result.value) && !TREE_OVERFLOW_P (arg.value))
> overflow_warning (loc, result.value);
It seems like you can move the new hunk a bit above so that we don't call
build_unary_op in a case when taking the address of a built-in function.
Unfortunately, it doesn't seem possible to do this error in build_unary_op
or in function_to_pointer_conversion :(.
Marek
More information about the Gcc-patches
mailing list