This is the mail archive of the
mailing list for the GCC project.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
- From: David Brown <david at westcontrol dot com>
- To: Warren D Smith <warren dot wds at gmail dot com>, <gcc at gcc dot gnu dot org>
- Cc: Joseph Myers <joseph at codesourcery dot com>
- Date: Tue, 26 Jul 2016 19:17:51 +0200
- Subject: Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
- Authentication-results: sourceware.org; auth=none
- References: <CAAJP7Y3cHYEOpdhZUXF1PZAJ=vkKoozRiPgwm2V_jH_T63XTKw@mail.gmail.com> <CAH6eHdRrmRWARhbcqWbqV07Y=SZp+Hsiv5-42y2k28CHqP4+UQ@mail.gmail.com> <CAAJP7Y0oRZmE4qS=shs4m7EWjWK2RfZdK2NSe1Kx1ZUT6W=QZw@mail.gmail.com> <alpine.DEB.email@example.com> <CAAJP7Y13cQ6WkxL_dPpBbk7rkCvAVwqEZ6HJzYuZ4nNkpfpu9w@mail.gmail.com>
On 26/07/16 16:55, Warren D Smith wrote:
> On 7/26/16, Joseph Myers <firstname.lastname@example.org> wrote:
>> On Tue, 26 Jul 2016, Warren D Smith wrote:
>>> (And in the case of uint4_t, it actually would not even BE an
>>> "extension" since as I said,
>>> the standard already allows providing other sizes.)
>> Only sizes which are an integer number of bytes with no padding bits.
> "The C99 standard includes definitions of several new integer types to
> enhance the portability of programs. The already available basic
> integer types were deemed insufficient, because their actual sizes are
> implementation defined and may vary across different systems... All
> new types are defined in <inttypes.h> header (cinttypes header in C++)
> and also are available at <stdint.h> header (cstdint header in C++).
> The types can be grouped into the following categories:
> * Exact-width integer types which are guaranteed to have the same
> number N of bits across all implementations. Included only if it is
> available in the implementation..."
> This wikipedia page nowhere says it must be an integer number of bytes
> with no padding.
Wikipedia does not define C - the C standards define C. And yes, all
types (including extended integer types) in C must be an integer number
of bytes. Padding bits are allowed, however.
So there is nothing (except sanity) to stop an implementation with 8-bit
chars having a 12-bit integer type that is stored in a 16-bit lump. But
the only support C allows for an object of size 12 bits on such a
platform would be as a bitfield.
> And you will notice they *intentionally* chose to name them int8_t
> meaning 8 BITs wide, and *not* meaning 8 BYTEs wide, intentionally
> choosing those names presumably because they wanted to permit
> sizes not a multiple of 8.
No, the names were chosen to use bit sizes because a "bit" is clearly
defined as a single binary digit. A "byte" in C terms is not
necessarily 8 bits - the unambiguous term for a lump of 8 bits is
"octet". C defines a "byte" to be the smallest addressable unit of
memory, with the constraint of it being at least 8 bits. On a great
many systems, a "byte" is precisely 8 bits (i.e., CHAR_BIT == 8). But
on other systems it is different. I have worked on devices with 16-bit
"bytes" (not with gcc). On these systems, "uint16_t" is exactly the
same size as "uint16_t" on an x86 system, because the number of bits is
specified. But "uint8_t" simply does not exist on such systems, because
the hardware does not support direct access to such units.
> And they said "only if available in implementation" which gcc chose to
> interpret as
> "we're not going to make other sizes available, hahahaha." But gcc could choose
> to get ahead of the other compilers, leading not following, by
> making them available. If you were really ambitious you could provide int7_t
> etc (w.g. all integer sizes up to 64) but I am not asking for that
> level of ambition. I am asking merely for the easy sizes 1, 2 and 4
> which you plainly have already written
> the code to do, just change some numbers.
If this were as easy as you seem to think, and as useful as you seem to
think, then gcc would support different int sizes. In fact making any
kind of dedicated int1_t, int2_t or int4_t support would be difficult in
the compiler, and would still not do what you want - the rules of C
insist that you be able to take the address of objects of these types,
and addresses of different objects are different. Thus the only legal
implementation of "int4_t" would have four bits for the data content and
padding bits to make up the rest of the byte (typically 8 bits).
> You are free to attack the standards bodies as being idiots. But they weren't
> being idiots in this decision.
I don't believe anyone other than you is attacking anyone, or calling
anyone "idiots". The gcc developers are very well aware of the
standards, including both the flexibility and freedoms they give. They
are also very well aware of the desires of programmers, and the
practical limitations of compilers and tools. So while they know the
standards allow the possibility of an "int4_t" extended integer type,
they know it would not be useful (it would not do what you think it
would do), as well as being a significant effort to implement.