Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ proposal: There are exactly 8 bits in a byte

open-std.org

Post reply on HN
Print view View original

181–190 of 357 posts

Re: C++ proposal: There are exactly 8 bits in a byte

#181

Post by dullcrisp »

Spivak wrote: post #156
Laremere wrote: post #144

Earlier quoted context omitted.

Zig is even better: 1. u8 and i8 are 8 bits. 2. u16 and i16 are 16 bits. 3. u32 and i32 are 32 bits. 4. u64 and i64 are 64 bits. 5. Arithmetic is an explicit choice. '+' overflowing is illegal behavior (will crash in debug and releasesafe), '+%' is 2's compliment wrapping, and '+|' is saturating arithmetic. Edit: forgot to mention @addWithOverflow(), which provides a tuple of the original type and a u1; there's also…

How does 5 work in practice? Surely no one is actually checking if their arithmetic overflows, especially from user-supplied or otherwise external values. Is there any use for the normal +?

You think no one checks if their arithmetic overflows?

Re: C++ proposal: There are exactly 8 bits in a byte

#182

Post by dullcrisp »

gerdesj wrote: post #100
WalterBright wrote: post #90

D made a great leap forward with the following: 1. bytes are 8 bits 2. shorts are 16 bits 3. ints are 32 bits 4. longs are 64 bits 5. arithmetic is 2's complement 6. IEEE floating point and a big chunk of wasted time trying to abstract these away and getting it wrong anyway was saved. Millions of people cried out in relief! Oh, and Unicode was the character set. Not EBCDIC, RADIX-50, etc.

"1. bytes are 8 bits" How big is a bit?

At least 2 or 3

Re: C++ proposal: There are exactly 8 bits in a byte

#183

Post by fourier54 »

basementcat wrote: post #177
gerdesj wrote: post #100

Earlier quoted context omitted.

"1. bytes are 8 bits" How big is a bit?

A bit is a measure of information theoretical entropy. Specifically, one bit has been defined as the uncertainty of the outcome of a single fair coin flip. A single less than fair coin would have less than one bit of entropy; a coin that always lands heads up has zero bits, n fair coins have n bits of entropy and so on. https://en.m.wikipedia.org/wiki/Information_theory https://en.m.wikipedia.org/wiki/Entropy_(inform…

That is a bit in information theory. It has nothing to do with the computer/digital engineering term being discussed here.

Re: C++ proposal: There are exactly 8 bits in a byte

#184

Post by joelignaatius »

bcoates wrote: post #176

I have mixed feelings about this. On the one hand, it's obviously correct--there is no meaningful use for CHAR_BIT to be anything other than 8. On the other hand, it seems like some sort of concession to the idea that you are entitled to some sort of just world where things make sense and can be reasoned out given your own personal, deeply oversimplified model of what's going on inside the computer. This approach can…

As with any highly used language you end up running into what I call the COBOL problem. It will work for the vast majority of cases except where there's a system that forces an update and all of a sudden a traffic control system doesn't work or a plane falls out of the sky.

You'd have to have some way of testing all previous code in the compilation (pardon my ignorance if this is somehow obvious) to make sure this macro isn't already used. You also risk forking the language with any kind of breaking changes like this. How difficult it would be to test if a previous code base uses a charbit macro and whether it can be updated to the new compiler sounds non obvious. What libraries would then be considered breaking? Would interacting with other compiled code (possibly stupid question) that used charbit also cause problems? Just off the top of my head.

I agree that it sounds nonintuitive. I'd suggest creating a conversion tool first and demonstrating it was safe to use even in extreme cases and then make the conversion. But that's just my unenlightened opinion.

Re: C++ proposal: There are exactly 8 bits in a byte

#185

Post by Negitivefrags »

bee_rider wrote: post #171
stephencanon wrote: post #158

Earlier quoted context omitted.

Numerical analysis people do not like it. Having _explicitly controlled_ wider accumulation available is great. Having compilers deciding to do it for you or not in unpredictable ways is anathema.

It isn’t harmful, right? Just like getting a little accuracy from a fused multiply add. It just isn’t useful if you can’t depend on it.

It can be harmful. In GCC while compiling a 32 bit executable, making an std::map can cause infinite loops or crashes in your program.

This is because when you insert a value into the map, it has 80 bit precision, and that number of bits is used when comparing the value you are inserting during the traversal of the tree.

After the float is stored in the tree, it's clamped to 32 bits.

This can cause the element to be inserted into into the wrong order in the tree, and this breaks the assumptions of the algorithm leaidng to the crash or infinite loop.

Compiling for 64 bits or explicitly disabling x87 float math makes this problem go away.

I have actually had this bug in production and it was very hard to track down.

Re: C++ proposal: There are exactly 8 bits in a byte

#186

Post by lf37300 »

bee_rider wrote: post #171
stephencanon wrote: post #158

Earlier quoted context omitted.

Numerical analysis people do not like it. Having _explicitly controlled_ wider accumulation available is great. Having compilers deciding to do it for you or not in unpredictable ways is anathema.

It isn’t harmful, right? Just like getting a little accuracy from a fused multiply add. It just isn’t useful if you can’t depend on it.

If not done properly, double rounding (round to extended precision then rounding to working precision) can actually introduce larger approximation error than round to nearest working precision directly. So it can actually make some numerical algorithms perform worse.

Re: C++ proposal: There are exactly 8 bits in a byte

#187

Post by blt »

Negitivefrags wrote: post #185
bee_rider wrote: post #171

Earlier quoted context omitted.

It isn’t harmful, right? Just like getting a little accuracy from a fused multiply add. It just isn’t useful if you can’t depend on it.

It can be harmful. In GCC while compiling a 32 bit executable, making an std::map can cause infinite loops or crashes in your program. This is because when you insert a value into the map, it has 80 bit precision, and that number of bits is used when comparing the value you are inserting during the traversal of the tree. After the float is stored in the tree, it's clamped to 32 bits. This can cause the element to be…

dang that's a good war story.

Re: C++ proposal: There are exactly 8 bits in a byte

#188

Post by Spivak »

dullcrisp wrote: post #181
Spivak wrote: post #156

Earlier quoted context omitted.

How does 5 work in practice? Surely no one is actually checking if their arithmetic overflows, especially from user-supplied or otherwise external values. Is there any use for the normal +?

You think no one checks if their arithmetic overflows?

I'm sure it's not literally no one but I bet the percent of additions that have explicit checks for overflow is for all practical purposes indistinguishable from 0.

Re: C++ proposal: There are exactly 8 bits in a byte

#189

Post by ndesaulniers »

Negitivefrags wrote: post #185
bee_rider wrote: post #171

Earlier quoted context omitted.

It isn’t harmful, right? Just like getting a little accuracy from a fused multiply add. It just isn’t useful if you can’t depend on it.

It can be harmful. In GCC while compiling a 32 bit executable, making an std::map can cause infinite loops or crashes in your program. This is because when you insert a value into the map, it has 80 bit precision, and that number of bits is used when comparing the value you are inserting during the traversal of the tree. After the float is stored in the tree, it's clamped to 32 bits. This can cause the element to be…

Are you mixing up long double with float?

Re: C++ proposal: There are exactly 8 bits in a byte

#190

Post by jfbastien »

Negitivefrags wrote: post #185
bee_rider wrote: post #171

Earlier quoted context omitted.

It isn’t harmful, right? Just like getting a little accuracy from a fused multiply add. It just isn’t useful if you can’t depend on it.

It can be harmful. In GCC while compiling a 32 bit executable, making an std::map can cause infinite loops or crashes in your program. This is because when you insert a value into the map, it has 80 bit precision, and that number of bits is used when comparing the value you are inserting during the traversal of the tree. After the float is stored in the tree, it's clamped to 32 bits. This can cause the element to be…

10 years ago, a coworker had a really hard time root-causing a bug. I shoulder-debugged it by noticing the bit patterns: it was a miscompile of LLVM itself by GCC, where GCC was using an x87 fldl/fstpl move for a union { double; int64; }. The active member was actually the int64, and GCC chose FP moved based on what was the first member of the union... but the int64 happened to be the representation of SNaN, so the instructions transformed it quietly to a qNaN as part of moving. The "fix" was to change the order of the union's members in LLVM. The bug is still open, though it's had recent activity: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Post reply on HN