[cfe-commits] r146236 - in /cfe/trunk: lib/AST/ExprConstant.cpp test/Sema/builtins.c

[Abramo Bagnara]

Il 09/12/2011 03:04, Richard Smith ha scritto:
> Author: rsmith
> Date: Thu Dec  8 20:04:48 2011
> New Revision: 146236
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=146236&view=rev
> Log:
> Replace the implementation of __builtin_constant_p (which was based on the GCC
> documentation) with one based on what GCC's __builtin_constant_p is actually
> intended to do (discovered by asking a friendly GCC developer).
> 
> In particular, an expression which folds to a pointer is now only considered to
> be a "constant" by this builtin if it refers to the first character in a string
> literal.
> 
> This fixes a rather subtle wrong-code issue when building with glibc. Given:
> 
> const char cs[4] = "abcd";
> int f(const char *p) { return strncmp(p, cs, 4); }
> 
> ... the macro magic for strncmp produces a (potentially crashing) call to
> strlen(cs), because it expands to an expression starting with:
> 
>   __builtin_constant_p(cs) && strlen(cs) < 4 ? /* ... */
> 
> Under the secret true meaning of __builtin_constant_p, this is guaranteed to be
> safe!

Concerning the nature of __builtin_constant_p I'd like to understand why
__builtin_constant_p and __builtin_classify_type despite the fact that
they are very special and not true call expression (they don't evaluate
their arguments) they are handled by CallExpr node.

This seems very weird to me and incongruent with other design choices
(see the handling of __builtin_choose_expr).

Do we agree that __builtin_constant_p and __builtin_classify_type would
deserve to be represented by a node different from CallExpr?