https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 18 May 2015, kevin at koconnor dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110 > > --- Comment #12 from Kevin OConnor <kevin at koconnor dot net> --- > (In reply to Andreas Schwab from comment #11) > > Since typedef does not create a new type the effect of uint8_t is exactly > > the same as the type it is defined from. Thus if uint8_t is defined from > > unsigned char then uint8_t is a character type. > > Yes, of course. My point is that gcc does not need to define uint8_t / > __UINT8_TYPE__ as 'unsigned char'. Instead it could define it as a new > integer > type (eg, __gcc_uint8_t) that is an 8-bit integer that does not alias. Yes, agreed. Like {signed,unsigned,} __gcc_int8_t or so... > As before, I understand if the cost of doing this is too high, but it's > unfortunate that there currently does not appear to be any way to define a > pointer to an 8-bit integer that doesn't alias. Another possibility would be to introduce an attribute similar to may_alias, "not_alias" so you can do typedef unsigned char uint8_t __attribute__((no_alias)); or sth like that. As that wouldn't alias with typedef unsigned char my_uint8_t __attribute__((no_alias)); the effects might be surprising though.
