On 27/08/15 17:09, Martin Sebor wrote: >> Is it fair to say that the main use of extended integers is to "fill the >> gaps" if the sequence char, short, int, long, long long has missing >> sizes? Such as if an architecture defines int to be 64-bit and short to >> be 32-bit, then you could have an extended integer type for 16-bit? > > Something like that. The extended integer types were invented by > the committee in hopes of a) easing the transition from 16-bit > to 32-bit to 64-bit implementations and b) making it possible for > implementers targeting new special-purpose hardware to extend the > language in useful and hopefully consistent ways to take advantage > of the new hardware. One idea was to support bi-endian types in > the type system. There was no experience with these types when > they were introduced and I don't have the impression they've been > as widely adopted as had been envisioned. Intel Bi-endian compiler > does provide support for "extended" mixed-endian types in the same > program. > By "bi-endian types", you mean something like "int_be32_t" for a 32-bit integer that is viewed as big-endian, regardless of whether the target is big or little endian? (Alternatively, you could have "big_endian", etc., as type qualifiers.) That would be an extremely useful feature - it would make things like file formats, file systems, network protocols, and other data transfer easier and neater. It can also be very handy in embedded systems at times. I know that the Diab Data embedded compiler suite, now owned by Wind River which is now owned by Intel, has support for specifying endianness - at least in structures. If I remember correctly, it is done with qualifiers rather than with extended integer types. I wonder if such mixed endian support would be better done using name address spaces, rather than extended integer types? (Sorry for changing the topic of the thread slightly - control of endianness is one of the top lines in my wish-list for gcc features.) David
