Re: Invalid code in <limits>

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Mark Mitchell <mark@codesourcery.com> writes:

| The C++ standard library <limits> code contains this pattern:
| 
|       static const bool has_infinity
| 	= __builtin_huge_valf () / 2 == __builtin_huge_valf ();
| 
| in several places.
| 
| Syntactically, a function call cannot appear in a constant-expression,
| which is what is required for a static member initializer.  

True.  But, my recollection at the time when that work was done was
that __builtin_huge_valf() (and similirar "function") should be
treated as compile-time constants, i.e. the expression 

  __builtin_huge_valf () / 2 == __builtin_huge_valf ()

should be handled as an integral-constant by  the compiler.

| I've got patches to correctly diagnose this error, and they're
| tripping on this code in the standard library.
| 
| Theoretically, we could try to exempt built-ins, but it is going to
| get very complicated to try to get that right in the presence of
| templates/dependent names/two-phase name lookup.  We really don't want
| to go there.

I hear you and understand your worry.  However, since the builtins,
i.e. any identifier with prefix "__builtin_" designate compiler
generated entities, I think the compiler has the necessary information
to perform the name lookup and to apply semantics restrictions.

| One way to fix this would to be to introduce magic variables as well
| as the builtin functions.  These magic variables would be defined
| like:
| 
|   static const __builtin_huge_valf_constant = <the value>;
| 
| Or maybe have the preprocessor define symbols ala __SIZE_TYPE__ for
| this purpose?
| 
| Or maybe magic keywords?

I believe that a general framework for "__builtin_" names (designating
compiler generated entities) is more scalable than relying on CPP.

  1) Use general rules to decide whether it is dependent;
  2) else perform lookup at the point of use and fold.

-- Gaby