`abi' namespace

[Martin von Loewis]

> I think that's irrelevant.  We're not putting any of this in standard
> headers.
> 
> If we're willing to put __ in our symbol names, we don't really need
> a namespace of our own.

The question is whether a user could ever construct out symbols by
declaring well-formed C++, and what the consequences of defining the
symbols in user code would be.

For example, if the user writes

#include <cstdio>
namespace abi {
  extern "C" void longjmp_unwind (jmp_buf env, int val){
   std::printf("Hello, world\n");
  }
}

using namespace abi;

int main()
{
  jmp_buf foo;
  longjmp_unwind(foo,0);
}

then he's got a well-formed C++ program, with a well-defined
meaning. Under our ABI, all kinds of things could happen - for
example, the code might be rejected because of a duplicate symbol.

In the specific case of longjmp_unwind, I don't fully understand
whether the plan is to expose this to the application developer, thus
extending the C++ API (rather than defining an ABI).

In the case of the RTTI types, the problem is more serious: Even if
there is no intention of exposing the interface to the programmer, the
programmer still might in conflicts when writing valid code.

So, I support Nathan's proposal of calling the namespace __abi: This
is a reserved name, and no well-formed C++ program should use that.
_ABI is possible alternativ with the same properties.

Even if the longjmp_unwind is user-callable, I'd prefer to leave the
decision to expose it to the implementation, so that compilers that
chose to offer pedantic C++ compliance still have the option of
providing ABI compliance as well.

Regards,
Martin