|
From: | David Brown |
Subject: | Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__() |
Date: | Tue, 01 Nov 2011 15:26:53 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 |
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) #endifI 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).
[Prev in Thread] | Current Thread | [Next in Thread] |