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

[Ben Smith]

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.


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