Live data from Hacker News

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

open-std.org

211–220 of 357 posts

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

#211
post #188

Earlier quoted context omitted.

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.

Lots of secure code checks for overflow

    fillBufferWithData(buffer, data, offset, size)
You want to know that offset + size don't wrap past 32bits (or 64) and end up with nonsense and a security vulnerability.

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

#212
post #142

Earlier quoted context omitted.

Wow. https://theminimumyouneedtoknow.com/ https://lscs-software.com/LsCs-Roadmap.html "Many of us got our first exposure to Qt on OS/2 in or around 1987." Uh huh. > someone always has a use case; No he doesn't. He's just unhinged. The machines this dude bitches about don't even have a modern C++ compiler nor do they support any kind of display system relevant to Qt. They're never going to be a target for Qt. Further…

Yeah, I think many of their arguments are not quite up to snuff. I would be quite interested how 1s compliment is faster, it is simpler and thus the hardware could be faster, iff you figure out how to deal with the drawbacks like -0 vs +0 (you could do it in hardware pretty easily...) Buuuut then the Unisys thing. Like you say they dont make processors (for the market) and themselves just use Intel now...and even if…

> The one point he does have is interoperability, which if a lot of (especially medical) equipment uses 1s compliment

No it’s completely loony. Note that even the devices he claims to work with for medical devices are off the shelf ARM processors (ie what everybody uses). No commonly used commodity processors for embedded have used 1’s complement in the last 50 years.

> equipment uses 1s compliment because its cheaper (in terms of silicon)

Yeah that makes no sense. If you need an ALU at all, 2s complement requires no more silicon and is simpler to work with. That’s why it was recommended by von Neumann in 1945. 1s complement is only simpler if you don’t have an adder of any kind, which is then not a CPU, certainly not a C/C++ target.

Even the shittiest low end PIC microcontroller from the 70s uses 2s complement.

It is possible that a sensing device with no microprocessor or computation of any kind (ie a bare ADC) may generate values in sign-mag or 1s complement (and it’s usually the former, again how stupid this is) - but this has nothing to do with the C implementation of whatever host connects to it which is certainly 2s. I guarantee you no embedded processor this dude ever worked with in the medical industry used anything other than 2s complement - you would have always needed to do a conversion.

This truly is one of the most absurd issues to get wrapped up on. It might be dementia, sadly.

https://github.com/RolandHughes/ls-cs/blob/master/README.md

Maintaining a fork of a large C++ framework (well of another obscure fork) where the top most selling point is a fixation on avoiding C++20 all because they dropped support for integer representations that have no extant hardware with recent C++ compilers - and any theoretical hardware wouldn’t run this framework anyway, that doesn’t seem well attached to reality.

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

#213
post #80

Previously, in JF's "Can we acknowledge that every real computer works this way?" series: "Signed Integers are Two’s Complement" https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09... >

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

At the very least, division by zero should not be undefined for floats.

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

#214
post #89

Earlier quoted context omitted.

I've worked on a machine with 9-bit bytes (and 81-bit instructions) and others with 6-bit ones - nether has a C compiler

I think the pdp-10 could have 9 bit bytes, depending on decisions you made in the compiler. I notice it's hard to Google information about this though. People say lots of confusing, conflicting things. When I google pdp-10 byte size it says a c++ compiler chose to represent char as 36 bits.

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.

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

#215
post #15

During an internship in 1986 I wrote C code for a machine with 10-bit bytes, the BBN C/70. It was a horrible experience, and the existence of the machine in the first place was due to a cosmic accident of the negative kind.

C itself was developed on machines that had 18 bit ints.

B was developed on the PDP-7. C was developed on the PDP-11.

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

#217
post #166
post #15

During an internship in 1986 I wrote C code for a machine with 10-bit bytes, the BBN C/70. It was a horrible experience, and the existence of the machine in the first place was due to a cosmic accident of the negative kind.

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.

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

#218
post #174
post #39

I'm totally fine with enforcing that int8_t == char == 8-bits, however I'm not sure about spreading the misconception that a byte is 8-bits. A byte with 8-bits is called an octet. At the same time, a `byte` is already an "alias" for `char` since C++17 anyway[1]. [1] https://en.cppreference.com/w/cpp/types/byte

My first experience with computers was 45 years ago, and a "byte" back then was defined as an 8-bit quantity. And in the intervening 45 years, I've never come across a different meaning for "byte". I'll ask for a citation for a definition of "byte" that isn't 8-bits.

1979 is quite recent as computer history goes, and many conventions had settled by then. The Wikipedia article discusses the etymology of "byte" and how the definition evolved from loosely "a group of bits less than a word" to "precisely 8 bits". https://en.wikipedia.org/wiki/Byte

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

#219

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.

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…

Eh I like the nice names. Byte=8, short=16, int=32, long=64 is my preferred scheme when implementing languages. But either is better than C and C++.

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

#220

Earlier quoted context omitted.

A bit is either a 0 or 1. A byte is the smallest addressable piece of memory in your architecture.

Technically the smallest addressable piece of memory is a word.

Every ISA I've ever used has used the term "word" to describe a 16- or 32-bit quantity, while having instructions to load and store individual bytes (8 bit quantities). I'm pretty sure you're straight up wrong here.
Post reply on HN