[cfe-dev] Predefined stdint macros (i.e. __UINT8_TYPE__, etc.)

[Alp Toker]

On 12/06/2014 01:12, Reid Kleckner wrote:
> On Wed, Jun 11, 2014 at 2:46 PM, Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>
>
>     On 12/06/2014 00:33, Ben Smith wrote:
>
>         On Wed, Jun 11, 2014 at 12:14 PM, Chandler Carruth
>         <chandlerc at google.com <mailto:chandlerc at google.com>
>         <mailto:chandlerc at google.com <mailto:chandlerc at google.com>>>
>         wrote:
>
>
>             On Wed, Jun 11, 2014 at 8:10 PM, Ben Smith
>         <binji at chromium.org <mailto:binji at chromium.org>
>             <mailto:binji at chromium.org <mailto:binji at chromium.org>>>
>         wrote:
>
>                 Hello cfe-dev,
>
>                 Clang defines a subset of the predefined stdint macros
>         that
>                 GCC does. In particular, GCC defines the following
>         macros many
>                 of which are not defined in Clang:
>
>                 __U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}__
>                 __U?INT{PTR,MAX}_{MAX,TYPE}__
>
>                 Some of these macros are used in newlib's stdint.h, if
>         they
>                 exist. It seems that it hasn't been thoroughly tested with
>                 Clang, however, as some macros are assumed to exist.
>
>                 Is it worth adding these to Clang?
>
>
>             Yes, we should try to be compatible here, and generally it
>         seems
>             reasonable to define the fully expanded set of these.
>
>
>         Great, I'll make a CL adding these.
>
>
>     Be sure to put them behind !MSVCCompat* as we've been seeing
>     problem reports about GCC definitions confusing MSVC code recently.
>
>
> I don't agree with this necessarily.  If the macros don't actively 
> conflict with MSVC, I would add them to the set of integer types that 
> we currently define.

How so? I'm pretty sure we want to keep the predefined macros aligned 
with MSVC when in full compatibility mode for now. We're not always 
consistent but that was the idea..

>
> The problem with the __EXCEPTIONS macro was that exceptions don't work 
> in the MSVC ABI yet.

If we start defining other macros, especially well-known GNU ones, 
there's a risk that random bits of GCC-specific code will get enabled in 
portable headers..

> Once they do work, I would like to define __EXCEPTIONS so that 
> portable headers that detect the GCC macro will Just Work.

If an in-between mode like that is something you want (and I suspect it 
*isn't* for most of our users), how about holding on a couple of days 
for the prospective -fms-compatibility -fgcc-compatibility?

Adding these unconditionally now just adds more work to make the switch.

Alp.

-- 
http://www.nuanti.com
the browser experts