On 26/07/16 16:55, Warren D Smith wrote: > On 7/26/16, Joseph Myers <jos...@codesourcery.com> 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. > > wikipedia: > "The C99 standard includes definitions of several new integer types to > enhance the portability of programs.[2] 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.
