Re: --std vs __intN

[Marc Glisse <marc dot glisse at inria dot fr>]

(still talking, since the maintainers are keeping quite)

On Fri, 6 Jun 2014, DJ Delorie wrote:

> To parameterize the libstdc++ stuff, I have gcc export these test
> macros (and related ones as needed, which give the actual types and
> sizes):
>
> __GLIBCXX_USE_INT_N_0
> __GLIBCXX_USE_INT_N_1
> __GLIBCXX_USE_INT_N_2
> __GLIBCXX_USE_INT_N_3
> . . .
>
> where each N_* is one of the __int<N> types, but with no guarantee
> which is which (i.e. INT_N_0 might be __int20 with INT_N_1 being
> __int128, etc)

The USE macro may not be needed, making them equivalent to 
defined(MACRO_GIVING_THE_TYPE) seems good enough to me.

> So the question becomes... what additional conditions should be
> required to set those macros?
>
> For backwards compatibility, I suspect disabling the one for N=128
> when __STRICT_ANSI__ would have been set should do it.  That leaves
> the target-specific ones enabled to cover size_t.

In my opinion, we don't need to preserve that __STRICT_ANSI__ behavior. If 
someone writes __int128 without __extension__, they get a pedantic 
warning. I assume the same will be true with __intN (but they won't get 
any warning if they get the type as a difference of pointers, or through 
the size_t typedef). Removing the numeric_limits specialization doesn't 
seem to bring any useful extra. If you have a compiler option so that 
__int20 is not available (the name is not recognized by front-ends), 
automatically the macros won't list it and the library won't specialize 
for it, compiler and library stay in sync.

At least it seems the easiest to implement, and to understand for users.

--
Marc Glisse