Recent searches
Search options
Proposing that C++ acknowledge that there are exactly 8 bits in a byte.
I’d love feedback, especially from embedded / DSP folks who think this is a terrible idea.
https://isocpp.org/files/papers/P3477R0.html
@jfbastien As someone who's been doing C++ embedded development for quite a few years, I can't remember the last time I saw a non 8 bit byte.
Certainly not in the last decade.
Very much in favor of mandating CHAR_BIT == 8.
@jfbastien (for that matter I would also like to formalize that integers are twos complement and signed overflow wraps, which is how literally every mainstream ISA works anyway. It should not be UB)
@azonenberg @jfbastien iirc integers are two's complement already, but signed overflow is still UB
@whitequark @jfbastien Yeah and I am very much im favor of making the C++ standard reflect the realities of the 99.99% of hardware everyone actually uses and not UB things because some architecture from the 1970s does it differently.
For example defining that sizeof(&P) == sizeof(&Q) for any P and Q. And allowing printf(%p) to be used directly on any pointer type as a consequence.
Make the actual size implementation defined, by all means. As long as it's the same for any two pointer types.
@azonenberg @whitequark
Yeah I wrote that paper and gave a talk about the outcome https://youtu.be/JhUxIVf1qok?si=aSPEivvr84c27pVk
@jfbastien @whitequark An opt-in overflowing integer type would be fine by me (i.e. "int32_overflow_t" or similar). As long as there's a way to do it in a well-defined manner when I want to.
@azonenberg @jfbastien @whitequark 1 for each of the different possible behaviors, IMO: int32_wrap_t, int32_sat_t, and int32_trap_t
@egallager @jfbastien @whitequark I would not be opposed to that. And then software emulate any that aren't natively supported by hardware (with some means of querying if this is being done).
@azonenberg @egallager @jfbastien soooo... Rust's integer types, more or less?
@whitequark @egallager @jfbastien Similar. It looks like in rust saturation is an operator (saturating_add) rather than a type "integer with saturating operations".
I don't have strong feelings on how it's done in C++ other than wanting a standard way to get overflowing, saturating, or trapping behavior on demand.
@jfbastien @azonenberg @whitequark @egallager this is nice and clearly useful for many things but I really hope this all stays explicit and opt-in. Usual behaviour may be UB in the spec, but in practice it is very well defined in all not alien implementations.
using these different types will have very different consequences on the generated code and the programmer should be aware of them.
no one imagined new declaration specifiers for these behaviours ? or something via __attribute?
@azonenberg @whitequark @egallager @jfbastien @ and ^ have room for a saturating operator syntax, e.g. "a +^ b". But I'm concerned about how all of this interacts with integer promotion. A saturating type might be easier to define new promotion rules for? Or maybe "a +@16 b", i.e. explicit width?