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

[Alp Toker]

On 12/06/2014 23:36, Richard Smith wrote:
> On Thu, Jun 12, 2014 at 1:32 PM, Richard Smith <richard at metafoo.co.uk 
> <mailto:richard at metafoo.co.uk>> wrote:
>
>     On Wed, Jun 11, 2014 at 3:29 PM, Alp Toker <alp at nuanti.com
>     <mailto:alp at nuanti.com>> wrote:
>
>
>         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> <mailto: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>>
>                     <mailto: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>>
>                         <mailto: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..
>
>
>     Our builtin stdint.h uses these macros; we need to provide them in
>     all modes.
>
>
> Hmm, maybe we could keep the current set of __INT*_TYPE__ (that we use 
> in stdint.h) visible in all modes, but make the additional macros be 
> GCC-only. Or perhaps we should tell the newlib folks that they 
> shouldn't be relying on compiler implementation details, and should 
> just include stdint.h. =)

That was my line of thinking ;-)

I'm more interested in tucking away the GXX and __GNUC__ macros to be 
honest, and getting __VERSION__ to not lie unless in GCCCompat mode but 
these would be nice-to-haves.

Alp.

>
>             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
>
>         _______________________________________________
>         cfe-dev mailing list
>         cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>         http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>

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