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 <[email protected] > 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
