18.01.2014 17:47, Martin Husemann wrote:
> Do not rely on int8_t (and friends) not being preprocessor
> symbols (or symbols expanding to themselves). On NetBSD (for example) the
> glue(u, SDATA_TYPE) results in u__int8_t, which is undefined. There is no way
> to stop cpp expanding inner macros,
Am 18.01.2014 14:47, schrieb Martin Husemann:
> Do not rely on int8_t (and friends) not being preprocessor
> symbols (or symbols expanding to themselves). On NetBSD (for example) the
> glue(u, SDATA_TYPE) results in u__int8_t, which is undefined. There is no way
> to stop cpp expanding inner ma
On 01/18/2014 05:59 AM, Peter Maydell wrote:
> On 18 January 2014 13:47, Martin Husemann wrote:
>> Do not rely on int8_t (and friends) not being preprocessor
>> symbols (or symbols expanding to themselves). On NetBSD (for example) the
>> glue(u, SDATA_TYPE) results in u__int8_t, which is undefi
On 18 January 2014 13:47, Martin Husemann wrote:
> Do not rely on int8_t (and friends) not being preprocessor
> symbols (or symbols expanding to themselves). On NetBSD (for example) the
> glue(u, SDATA_TYPE) results in u__int8_t, which is undefined. There is no way
> to stop cpp expanding inne
Do not rely on int8_t (and friends) not being preprocessor
symbols (or symbols expanding to themselves). On NetBSD (for example) the
glue(u, SDATA_TYPE) results in u__int8_t, which is undefined. There is no way
to stop cpp expanding inner macros, so just add the few lines explicitly and
get ri
