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

261–270 of 357 posts

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

#261

Post by Negitivefrags »

ptsneves wrote: post #227
jfbastien wrote: post #190

Earlier quoted context omitted.

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 i…

It also affected eMacs compilation and the fix is in the trunk now. Wow 11 years for such a banal minimal code trigger. I really don’t quiet understand how we can have the scale of infrastructure in operation when this kind of infrastructure software bugs exist. This is not just gcc. All the working castle of cards is an achievement by itself and also a reminder that good enough is all that is needed. I also highly d…

If you think that’s bad let me tell you about the time we ran into a bug in memmove.

It had to be an unaligned memmove and using a 32 bit binary on a 64 bit system, but still! memmove!

And this bug existed for years.

This caused our database replicas to crash every week or so for a long time.

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

#262

Post by bregma »

stkdump wrote: post #208
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.

I mean practically speaking in C++ we have (it just hasn't made it to the standard): 1. char 8 bit 2. short 16 bit 3. int 32 bit 4. long long 64 bit 5. arithmetic is 2s complement 6. IEEE floating point (float is 32, double is 64 bit) Along with other stuff like little endian, etc. Some people just mistakenly think they can't rely on such stuff, because it isn't in the standard. But they forget that having an ISO sta…

I work every day with real-life systems where int can be 32 or 64 bits, long long can be 64 or 128 bits, long double can be 64 or 80 or 128 bits, some systems do not have IEEE 754 floating point (no denormals!) some are big endian and some are little endian. These things are not in the language standard because they are not standard in the real world.

Practically speaking, the language is the way it is, and has succeeded so well for so long, because it meets the requirements of its application.

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

#263

Post by 112233 »

harry8 wrote: post #25

Is C++ capable of deprecating or simplifying anything? Honest question, haven't followed closely. rand() is broken,I;m told unfixable and last I heard still wasn't deprecated. Is this proposal a test? "Can we even drop support for a solution to a problem literally nobody has?"

they do it left and right when it meets their fancy, otherwise it is unconscionable.

Like making over "auto". Or adding "start_lifetime_as" and declaring most existing code that uses mmap non-conformant.

But then someone asks for a thing that would require to stop pretending that C++ can be parsed top down in a single pass. Immediate rejection!

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

#264

Post by stephencanon »

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’s absolutely harmful. It turns computations that would be guaranteed to be exact (e.g. head-tail arithmetic primitives used in computational geometry) into “maybe it’s exact and maybe it’s not, it’s at the compiler’s whim” and suddenly your tests for triangle orientation do not work correctly and your mesh-generation produces inadmissible meshes, so your PDE solver fails.

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

#266

Post by quietbritishjim »

seoulbigchris wrote: post #239
jsheard wrote: post #80

Earlier quoted context omitted.

Maybe specifying that floats are always IEEE floats should be next? Though that would obsolete this Linux kernel classic so maybe not. https://github.com/torvalds/linux/blob/master/include/math-e...

Which one? Remember the decimal IEEE 754 floating point formats exist too. Do folks in banking use IEEE decimal formats? I remember we used to have different math libs to link against depending, but this was like 40 years ago.

Nothing prevents banks (or anyone else) from using a compiler where "float" means binary floating point while some other native or user-defined type supports decimal floating point. In fact, that's probably for the best, since they'll probably have exacting requirements for that type so it makes sense for the application developer to write that type themselves.

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

#267

Post by [deleted] »

Ballas wrote: post #217
Isamu wrote: post #166

Earlier quoted context omitted.

I wrote code on a DECSYSTEM-20, the C compiler was not officially supported. It had a 36-bit word and a 7-bit byte. Yep, when you packed bytes into a word there were bits left over. And I was tasked with reading a tape with binary data in 8-bit format. Hilarity ensued.

That is so strange. If it were 9-bit bytes, that would make sense: 8bits+parity. Then a word is just 32bits+4 parity.

[deleted]

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

#268

Post by josefx »

paragraft wrote: post #121
josephg wrote: post #112

Earlier quoted context omitted.

Yep. Pity about getting chars / string encoding wrong though. (Java chars are 16 bits). But it’s not alone in that mistake. All the languages invented in that era made the same mistake. (C#, JavaScript, etc).

What's the right way?

I would say anyone mentioning a specific encoding / size just wants to see the world burn. Unicode is variable length on various levels, how many people want to deal with the fact that the unicode of their text could be non normalized or want the ability to cut out individual "char" elements only to get a nonsensical result because the following elements were logically connected to that char? Give developers a decent high level abstraction and don't force them to deal with the raw bits unless they ask for it.

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

#269

Post by larsbrinkhoff »

eqvinox wrote: post #258
larsbrinkhoff wrote: post #214

Earlier quoted context omitted.

PDP-10 byte size is not fixed. Bytes can be 0 to 36 bits wide. (Sure, 0 is not very useful; still legal.) I don't think there is a C++ compiler for the PDP-10. One of the C compiler does have a 36-bit char type.

Do you have any links/info on how that 0-bit byte worked? It sounds like just the right thing for a Friday afternoon read ;D

It should be in the description for the byte instructions: LDB, DPB, IBP, and ILDB. http://bitsavers.org/pdf/dec/pdp10/1970_PDP-10_Ref/

Basically, loading a 0-bit byte from memory gets you a 0. Depositing a 0-bit byte will not alter memory, but may do an ineffective read-modify-write cycle. Incrementing a 0-bit byte pointer will leave it unchanged.

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

#270

Post by rty32 »

harry8 wrote: post #25

Is C++ capable of deprecating or simplifying anything? Honest question, haven't followed closely. rand() is broken,I;m told unfixable and last I heard still wasn't deprecated. Is this proposal a test? "Can we even drop support for a solution to a problem literally nobody has?"

One obvious example is auto_ptr. And from what I can see it is quite successful -- in a well maintained C++ codebase using C++ 11 or later, you just don't see auto_ptr in the code.
Post reply on HN