[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] 24 bits (u)ints

From: David Brown
Subject: Re: [avr-gcc-list] 24 bits (u)ints
Date: Thu, 1 Dec 2016 10:45:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 30/11/16 17:07, Georg-Johann Lay wrote:
> On 30.11.2016 15:32, Paul "LeoNerd" Evans wrote:
>> On Wed, 30 Nov 2016 18:18:11 +0530
>> Senthil Kumar Selvaraj <address@hidden> wrote:
>>> Diogo Martins Silva writes:
>>>> Hello all.
>>>> The avr-gcc wiki (https://gcc.gnu.org/wiki/avr-gcc) lists 24 bits
>>>> (u)ints as an extension since version 4.7. How do I use them?
>>> Use __uint24 as the type. Like so
>>> $ cat test.c
>>> volatile __uint24 x;
>>> int main() {
>>>   x++;
>>>   x--;
>>> }
>> Is it possible to get that added to <stdint.h> as the expected names
>>   int24_t
>>   uint24_t
>> ?
> The C99 and later standards don't supply these types or reserve these
> identifiers.  Since C99, "int8_t" is an identifier that resides in the
> namespace of the implementation, whereas "int24_t" is still in the
> namespace of the application.  Hence, for the new 3-byte types names
> were chosen that are in the namespace of the implementation, i.e.
> reserved identifiers which start with "__" (__int24 and __uint24).
> If you like you can define such types in your application, but they
> should not go into any standard header.
> Johann

Actually, names such as int24_t and uint24_t /are/ reserved for the
implementation to use in <stdint.h>.  See 7.31.10 of the C11 standards
under "Future library directions".  (I don't know if the same applies to
C99 - I don't have that standard conveniently on hand.)  Types int24_t
and uint24_t are optional, even if the compiler supports them as an
integer type (unlike the 8, 16, 32 and 64 bit types).

However, if int24_t and uint24_t are defined in <stdint.h>, then the
implementation must also define printf and scanf format specifier macros
PRId24, PRIi24, etc., in <inttypes.h>.  This in turn implies that printf
and scanf must support the types.  These can be avoided by classifying
avr-gcc as a "freestanding" compiler rather than a "hosted" compiler,
but I believe the norm in gcc is that an integer type only goes in
<stdint.h> if it is completely supported throughout the compiler and
library, including printf support.

So in gcc on 64-bit systems, the __int128 and __uint128 types don't have
printf support, nor is there any way to make literals of these types
(assuming the target does not have 128-bit long long's) - thus they are
not considered "extended integer types" and don't have corresponding
<stdint.h> types.

For 24-bit integers in avr-gcc, it /would/ be possible to make a
conforming freestanding C implementation with the types defined in
<stdint.h> - but it would be inconsistent with other ports of gcc and
with the printf in the library, and therefore probably not a good idea.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]