JF BastienOct 16, 2024
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
P3477R0: There are exactly 8 bits in a byte

Show threadAndrew ZonenbergOct 16, 2024

@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.

Show threadAndrew ZonenbergOct 17, 2024
@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)
Show thread✧✦Catherine✦✧Oct 17, 2024
@azonenberg @jfbastien iirc integers are two's complement already, but signed overflow is still UB
Show threadAndrew Zonenberg

@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.

Oct 17, 2024 at 4:43amWeb
Show threadJF BastienOct 17, 2024
@azonenberg @whitequark
Yeah I wrote that paper and gave a talk about the outcome https://youtu.be/JhUxIVf1qok?si=aSPEivvr84c27pVk
CppCon 2018: JF Bastien “Signed integers are two's complement”

YouTube
Show threadAndrew ZonenbergOct 17, 2024
@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.
Show threadRep. Eric Gallager (no "h"!)Oct 17, 2024
@azonenberg @jfbastien @whitequark 1 for each of the different possible behaviors, IMO: int32_wrap_t, int32_sat_t, and int32_trap_t
Show threadAndrew ZonenbergOct 17, 2024
@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).
Show thread✧✦Catherine✦✧Oct 17, 2024
@azonenberg @egallager @jfbastien soooo... Rust's integer types, more or less?
Show threadAndrew ZonenbergOct 17, 2024

@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.

Show threadJF BastienOct 17, 2024
@azonenberg @whitequark @egallager
A subset of what you want is in C++26
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0543r3.html
P0543R3: Saturation arithmetic

Show thread✧✦Catherine✦✧Oct 17, 2024
@azonenberg @egallager @jfbastien it's also a type https://doc.rust-lang.org/std/num/struct.Saturating.html https://doc.rust-lang.org/std/num/struct.Wrapping.html
Saturating in std::num - Rust

Provides intentionally-saturating arithmetic on `T`.

Show threadequinoxOct 17, 2024
@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?
Show threadJean-Michaël CelerierOct 17, 2024
@azonenberg @whitequark @jfbastien sizeof(&P) can be != sizeof(&Q) though.. member function pointers, overloaded operator& come to mind
Show threadAndrew ZonenbergOct 17, 2024
@jcelerier @whitequark @jfbastien Sorry, I meant any pointer to object/data (vs function pointers).