But how many bytes are there in a word?
"Word" is an outdated concept we should try to get rid of.
C++ proposal: There are exactly 8 bits in a byte
21–30 of 357 posts
Re: C++ proposal: There are exactly 8 bits in a byte
#22One fun fact I found the other day: ASCII is 7 bits, but when it was used with punch cards there was an 8th bit to make sure you didn't punch the wrong number of holes. https://rabbit.eng.miami.edu/info/ascii.html
Re: C++ proposal: There are exactly 8 bits in a byte
#23JF Bastien is a legend for this, haha. I would be amazed if there's any even remotely relevant code that deals meaningfully with CHAR_BIT != 8 these days. (... and yes, it's about time.)
DSP chips are a common exception that people bring up. I think some TI made ones have 64 bit chars. Edit: I see TFA mentions them but questions how relevant C++ is in that sort of embedded environment.
Re: C++ proposal: There are exactly 8 bits in a byte
#24Not sure about that, seems pretty controversial to me. Are we forgetting about the UNIVACs?
Hopefully we are; it's been a long time, but as I remember indexing in strings on them is a disaster.
Yes, indexing strings of 6-bit FIELDATA characters was a huge headache. UNIVAC had the unfortunate problem of having to settle on a character code in the early 1960s, before ASCII was standardized. At the time, a military 6-bit character set looked like the next big thing. It was better than IBM's code, which mapped to punch card holes and the letters weren't all in one block.
[1] https://www.unisys.com/siteassets/collateral/info-sheets/inf...
Re: C++ proposal: There are exactly 8 bits in a byte
#25Honest 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?"
Re: C++ proposal: There are exactly 8 bits in a byte
#26Re: C++ proposal: There are exactly 8 bits in a byte
#27In a char, not in a byte. Byte != char
https://man7.org/linux/man-pages/man3/fgetc.3.html
fgetc(3) and its companions always return character-by-character input as an int, and the reason is that EOF is represented as -1. An unsigned char is unable to represent EOF. If you're using the wrong return value, you'll never detect this condition.
However, if you don't receive an EOF, then it should be perfectly fine to cast the value to unsigned char without loss of precision.
Re: C++ proposal: There are exactly 8 bits in a byte
#28Not sure about that, seems pretty controversial to me. Are we forgetting about the UNIVACs?
Given that Wikipedia says UNIVAC was discontinued in 1986 I’m pretty sure the answer is no and no!
Re: C++ proposal: There are exactly 8 bits in a byte
#29JF Bastien is a legend for this, haha. I would be amazed if there's any even remotely relevant code that deals meaningfully with CHAR_BIT != 8 these days. (... and yes, it's about time.)
The tms320c28x DSPs have 16 bit char, so e.g. the Opus audio codec codebase works with 16-bit char (or at least it did at one point -- I wouldn't be shocked if it broke from time to time, since I don't think anyone runs regression tests on such a platform). For some DSP-ish sort of processors I think it doesn't make sense to have addressability at char level, and the gates to support it would be better spent on bette…