On Sun, 28 Jun 2015, Martin Sebor wrote: > 2015-06-28 Martin Sebor <mse...@redhat.com> > > pr c/66516 > * c-tree.h (c_validate_addressable): New function. > * c-typeck.c (convert_arguments, parser_build_unary_op): Call it. > (build_conditional_expr, c_cast_expr, convert_for_assignment): Same. > (build_binary_op, c_objc_common_truthvalue_conversion): Same. > (c_validate_addressable): Define function.
I don't think c_validate_addressable is a good name - given that it's called for lots of things that aren't addressable, in contexts in which there is no need for them to be addressable, and doesn't do checks of addressability in contexts where they are actually needed and done elsewhere (e.g. checks for not taking the address of a register variable). The question seems to be something more like: is the expression used as an operand something it's OK to use as an operand at all? What is the logic for the list of functions above being a complete list of the places that need changes? > @@ -4477,11 +4486,22 @@ build_conditional_expr (location_t colon_loc, tree > ifexp, bool ifexp_bcp, > || TREE_CODE (TREE_TYPE (op2)) == ERROR_MARK) > return error_mark_node; > > + if (TREE_CODE (TREE_TYPE (ifexp)) == POINTER_TYPE > + && !c_validate_addressable (ifexp, > + EXPR_LOCATION (TREE_OPERAND (ifexp, 0)))) > + return error_mark_node; How can ifexp be of pointer type? It's undergone truthvalue conversion and should always be of type int at this point (but in any case, you can't refer to TREE_OPERAND (ifexp, 0) without knowing what sort of expression it is). > +/* For EXPR that is an ADDR_EXPR or whose type is a FUNCTION_TYPE, > + determines whether its operand can have its address taken issues > + an error pointing to the location LOC. > + Operands that cannot have their address taken are builtin functions > + that have no library fallback (no other kinds of expressions are > + considered). > + Returns true when the expression can have its address taken and > + false otherwise. */ Apart from the naming issue, the comment says nothing about the semantics of the function for an argument that's not of that form. > + error_at (loc, "builtin functions must be directly called"); "built-in" (see codingconventions.html). -- Joseph S. Myers jos...@codesourcery.com
