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

[Ben Smith]

On Wed, Jun 11, 2014 at 4:15 PM, Ben Smith <binji at chromium.org> 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..
>>
>>
>>
>>> 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.
>>
>>
> Well, this is my first LLVM change, so it probably will take a little time
> anyway. :)
>
> Question about FAST/LEAST types: how should I determine these for the
> target? I couldn't find anything appropriate in TargetInfo.
>

I've uploaded a patch for this here: http://reviews.llvm.org/D4141

I duplicated the assumption from stdint.h that the FAST types match the
LEAST types, and gated all of these new macros on !MSVCCompat.

-Ben


>
>
>> Alp.
>>
>>
>> --
>> http://www.nuanti.com
>> the browser experts
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140617/047ea2c3/attachment.html>