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

[Richard Smith]

On Thu, Jun 12, 2014 at 1:32 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> On Wed, Jun 11, 2014 at 3:29 PM, Alp Toker <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>> 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..
>
>
> 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. =)

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
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140612/7582d8c0/attachment.html>