Re: [PATCH v2 06/13] expression, evaluate: add support for recognizing address constants

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Mon, Jan 25, 2016 at 03:56:23PM +0100, Nicolai Stange wrote:
> Address constants [6.6(9)] constitute one of the types of constant
> expressions allowed in initializers [6.6(7)] for static storage
> duration objects [6.7.8(4)].
> 
> Introduce support for recognizing address constants created either
> - explicitly by referencing a static storage duration object by means
>   of the unary & operator
> - or implicitly by the use of an expression of array or function type.
> 
> Treat string literals as address constants.
> 
> Initially tag an expression as being an address constant at the
> primary expression level, i.e. upon encountering a symbol designating
> an object of static storage duration in primary_expression().
> 
> Carry these flags over to the *-preop wrapped expression created by
> evaluate_symbol_expression().
> 
> For the special case of string literals, tag them as address constants
> in evaluate_string().
> 
> Take care in evaluate_ptr_add() and evaluate_offset()
> to properly propagate the address constness flags from
> subexpressions to their parent expressions, namely the array ([])
> or structure member dereference (->, .) expressions.
> 
> Finally, do not strip away an *-preop wrapped expression's constness
> flags in evaluate_addressof().

There is two much thing in the description, this is a sure sign that the patch
should be splitted, like putting the part concerning strings in a separate one.

> @@ -1678,7 +1689,6 @@ static struct symbol *evaluate_addressof(struct expression *expr)
>  	}
>  	ctype = op->ctype;
>  	*expr = *op->unop;
> -	expr->flags = EXPR_FLAG_NONE;

Is this because it's already initialized so by the allocator?
if so, it can be moved to the patch that add this initialization
(because it's unrelated to the current change).


Good otherwise.


Luc