Re: Invalid code in <limits>

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

Mark Mitchell <mark@codesourcery.com> writes:

| --On Wednesday, January 29, 2003 09:30:42 AM -0500 Phil Edwards
| <phil@jaj.com> wrote:
| 
| > 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.
| 
| Again, all we need here is the notion of a builtin *value*.  

We already have it: It is written __builtin_fn(), marked as expanded
by the front-end and the fron-end  knows about its existence. 

| There's
| nothing scarier about adding those then adding lots of builtin
| *functions* that always return the same value.

It is scary because it makes evolution painful and long run
maintenance unnecessarily harder.

| The condition we could try to test for using the existing syntax is
| that (a) it's a builtin function, (b) there are no parameters, (c)
| the function has the "const" attribute, (d) it's on a special list
| of things we know how to fold.
| 
| The (b) requirement is perhaps not strictly necessary, but in order
| not to make things unbelievably complex you need it.

Not really:  you don't need sizeof() to be nullary.

| Furthermore, there are issues with name mangling:
| 
|   template <typename T>
|   void f(int (*)[__builtin_fn() + sizeof (T)])
| 
| needs a manglined name.  Do you mangle the builtin as a function call?

As said earlier, there several kinds of __builtin_xxx(): There are
those who are expanded bby the front-end, i.e. treated as dependent
constant value (e.g. __builtin_fn(T) is such thing) and there are full
flegged builtin functions like __builtin_puts().


| Or as the underlying value?

As the underlying value.

|  Is __builtin_strchr("abc", 'b') valid?

No, it isn't because it is BUILT_IN_NORMAL.

| We do not want to go here, and there is no compelling need.  It's
| perfectly possible to implement <limits> without using these extensions,
| and while still preserving scalability, flexibility, extensibility,

I beg to differ.  

How would you implement compiler support for type-traits?  Surely, you
won't propose a new keyword for each new type-id.  

I see no reason why we can't just solve that problem once for all
instead of multiplication of magic keywords.

-- Gaby