Re: Invalid code in <limits>

[Phil Edwards <phil at jaj dot com>]

On Wed, Jan 29, 2003 at 03:45:18PM +0100, Gabriel Dos Reis wrote:
> Phil Edwards <phil@jaj.com> writes:
> 
> [...]
> 
> | Perhaps we should try to evaluate and fold the expression before diagnosing
> | the presence of a function call?
> | 
> | Perhaps all __builtin_xxx functions which are capable of being in an
> | i.c.e. should simply have a certain attribute on them?  The compiler sees
> | 
> |     const static int foo = ......  fn() ...
> | 
> | and checks for the attribute on fn; if not there, it's an error.
> 
> Builtins are defined with various attributes, among which a bit to
> tell that the compiler *do* about the builtin and it is its
> responsability to make sense of it:
> 
>    /* Like DEF_LIB_BUILTIN, except that the function is expanded in the
>       front-end.  */
>    #undef DEF_FRONT_END_LIB_BUILTIN                        
>    #define DEF_FRONT_END_LIB_BUILTIN(ENUM, NAME, TYPE, ATTRS)      \
>      DEF_BUILTIN (ENUM, NAME, BUILT_IN_FRONTEND, TYPE, TYPE,       \
>                   true, true, false, ATTRS)
> 
> The basic machinery is already there.

Yes, I'm making use of it already.  :-)  Perhaps we can examine the "what
to do if the builtin cannot be expanded by the compiler" part; if we would
normally fall back on a library call, then issue an error if the builtin
appears in an i.c.e.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002