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. ;-) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev