[PATCH] Change __INT*_TYPE__ to be compatible with GCC

[Reid Kleckner]

Looks good to me.

Most people don't use __INT8_TYPE__ directly, so I think this change is
pretty safe.  Even if they do use it directly, they will have two behavior
changes:

- If they use -funsigned-char, __INT8_TYPE__ was unsigned and now it will
be explicitly signed.
- C++ overload resolution and template deduction has a tri-state of signed
char, unsigned char, and char, so a different overload / instantiation will
be chosen.

Both of these seem pretty corner-casey, and there will be no change if the
user is using stdint.h's int8_t.

---

One nit on the patch, which would probably be caught during testing:

 #ifdef __INT56_TYPE__
-typedef signed __INT56_TYPE__ int56_t;
-typedef unsigned __INT56_TYPE__ uint56_t;
+typedef__INT56_TYPE__ int56_t;

Lost a space here

+typedef __UINT56_TYPE__ uint56_t;



On Thu, Jul 24, 2014 at 5:24 AM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:

> On Sun, Jul 20, 2014 at 05:51:36PM +0200, Joerg Sonnenberger wrote:
> > On Wed, Jul 16, 2014 at 03:47:14PM +0200, Joerg Sonnenberger wrote:
> > > at the moment, users of __INT8_TYPE__ are expected to prefix it with an
> > > explicit signed. We recently got support for __UINTx_TYPE__, so the
> > > primary reason for that odity disappeared. I'd like to make our macros
> > > compatible with the simpler GCC definition, so that __INT8_TYPE__ is
> > > signed char and the others can be defined without signed. This
> > > potentially breaks out of tree users of __INTx_TYPE__, so I would like
> > > to get a consensus here first.
> >
> > Ping?
>
> Ping2?
>
> Joerg
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140728/586eb2d2/attachment.html>