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

[David Brown]

On 01/11/2011 15:14, Joerg Wunsch wrote:
> 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.

That certainly seems to be the case in gcc, at least according to the 
user documents:

<http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Optimize-Options.html#index-fstrict_002daliasing-721>

The reason I questioned the signed char case was from a quotation from 
the standards in a stackoverflow question, which suggests that it only 
applies to plain char and unsigned char.  I don't have a copy of the 
standards on-hand to check.  It may also be that it applies only to C++, 
not C.

<http://stackoverflow.com/questions/98650/what-is-the-strict-aliasing-rule/7005988#7005988>

> 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.

I hadn't thought of it that way, but you might be right here.

Of course, there are targets where uint8_t does not exist, and uint16_t 
(or even uint32_t) is an "unsigned char" and has the alias-anything 
properties.

But I think it is impossible in standard C (i.e., not using the mode 
attributes) to get a uint8_t without it being an "unsigned char" - thus 
it is normally considered safe to rely on its aliasing properties.

My concern is just with any possible differences between a mode-defined 
8-bit int and a char.

> 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).

I can't think of any such platforms.  Most targets that don't have 8-bit 
chars are either dinosaur mainframes, or particularly annoying DSPs. 
AFAIK, the DSPs that gcc supports (such as as the Blackfin) have 8-bit 
chars (though they might have 32-bit int_fast8_t).