Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()

[Joerg Wunsch]

As David Brown wrote:

> That might be okay.  However, why not do this:
> 
> #if defined(__DOXYGEN__)
> #define __attribute__(discard)
> #endif

I don't know whether doxygen's preprocessing stage will really work
correctly with that.  Otherwise, it might be fine.

> A "char *" can alias any other type, but an "int *" cannot - it will 
> only alias compatible types (signed and unsigned ints, const versions, 
> etc.).  I'm a little unclear about whether it is only plain char* and 
> unsigned char* that have this aliasing property, or if it also applies 
> to signed char* (I've seen conflicting references).

As per the C standard rationale, signedness considerations have been
kept out of any aliasing rules.

The "char" has been chosen simply because char pointers have
historically been used a lot to address arbitrary bytes which are
actually parts of larger objects.

Since (u)int8_t types are not described by the standard to also offer
this feature, you are technically not allowed to use pointers to these
types to alias parts of a larger object -- even though this leads to
the somewhat stupid situation that you have to resort to an `unsigned
char *' again for this, where you cannot be really sure (without other
checks) that the object it points to is really exactly 8 bits wide.

In practice, I don't think you'll observe any different behaviour
between an `unsigned char' and an `uint8_t' with GCC, unless
(obviously) working on a platform that does not offer 8-bit integers
at all (but I don't know whether such a platform exists where GCC has
ever been ported to).

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)