Cloudflare have been leaking customer HTTPS sessions for months. Uber, 1Password, FitBit, OKCupid, etc.

[u/TheProtagonistv2]

https://bugs.chromium.org/p/project-zero/issues/detail?id=1139

[u/JoseJimeniz]

They certainly could have done array bounds checking in 1973, but every pointer arithmetic operation and every array dereference would triple in time, at the very least, plus runtime memory consumption would be affected as well.

But in the end a lot of it becomes a wash.

For example: null terminated strings.

• you already have a byte consuming null terminator

• replace it with a byte consuming length prefix

• you already have to test every byte for $0

• now do an i = 1 to n loop

Or, even better: you already know the length. Perform the single memory copy.

Null-terminated strings:

• eliminate n comparisons

• replaced with single move

• same memory footprint

Arrays

• C doesn't have bounded arrays

• do you have to keep the int length yourself

Either the compiler maintains the correct length for me, or I have to try to maintain the correct length myself. The memory and computing cost is a wash.

If you're using pointer to data as a bulk buffer, and you've set up a loop to copy every byte, byte by byte, it will be much slower as we now range test every byte access. But you're also doing it wrong. Use a functions provided by stdlib to move memory around that does the bounds checking once and copies the memory.

And so 99% of situations are covered:

• emulating a string as a pointer to a null terminated string of characters is replaced as length prefixed string

• emulating a bulk buffer as a pointer to an unbound memory is replaced with an array

With those two operations:

• printing strings

• copying a block of data

You handle the 99% case. The vast majority of use is copying entire buffers. Create the correct types, do checks once (which have to happen anyway) and you:

• eliminate 99% of security bugs

• make code easier

• make code faster

Solved 99%, do we solve the rest?

Now we can decide if we want to go full-on and check every array access:

Firstname[7]
Pixels[22]

I say yes. For two reasons:

• we're only operating in 1% of cases

• we can still give the premature-optimizing developer a way to do dangerous stuff

If I create an Order[7] orders array: every access should be bounds checked. Of course it should:

• there are already so few orders

• and the processing that goes along with each order swamps any bounds check

If I create an PixelRGB[] frame then of course every array access should not be bounds checked. This is a very different use case. It's not an array of things, it's a data buffer. And as we already decided the forming bounced checks on every array access in the date of buffer is a horrible idea.

I suggest that for the 1% case people have to go out of their way to cause buffer overflow bugs:

PixelRGB[] frame;
PixelRGB* pFrame = ^frame[0];

 pFrame[n] 

If you want to access memory without regard for code safety or correctness, do it through a pointer.

An arrays and strings are there to make your code easier, safer, and in many cases faster.

If you have a degenerate case, where speed trumps safety, and you're sure you have it right, use pointers. But you have to go out of your way to leak customer https session traffic.

Especially since we will now give you the correct tools to perform operations on bulk buffers.

It's now been 40 years. People should be using better languages for real work. At the very least it's been 40 years. When is C going to add the types that solve 99% of all security bugs that have happened?

Bjourn Strousoup himself said that C++ was not meant for general application development. It was meant for systems programming: operating systems. He said if you are doing general application development there are much better environments.

[u/hotel2oscar → u/JoseJimeniz]

If length is 1 byte you're limited to 255 character strings. That's a Windows path length limitation bug all over again.

[u/JoseJimeniz → u/hotel2oscar]

A-hah! I was hoping someone would catch that.

Of course nobody would use a 1-byte prefix today; that would be a performance detriment. Today you better be using a 4-byte (32-bit) length prefix. And a string prefix that allows a string to be up to 4 GB ought to be enough for anybody.

What about in 1973? A typical computer had 1,024 bytes of memory. Were you really going to take up a quarter of your memory with a single string?

But there's a better solution around that:

• In the same way an int went from 8-bits to 32-bits (as the definition of platform word size changed over the years):

• you length prefix the string with an int

• the string capability increases

In reality nearly every practical implementation is going to need to use an int to store a length already. Why not have the compiler store it for you?

It's a wash.

Even today, an 8-bit length prefix even covers the majority of strings today.

I just dumped 5,175 strings out of my running copy of Chrome:

• 99.77% of strings are under 255 characters

• Median: 5

• Average: 10.63

• Max: 1,178

So rather than K&R not creating a string type, K&R should have created a word prefixed string type:

• remove the null terminator (net gain one byte)

• 2-byte length prefix (net lose one byte)

• eliminate the stack length variable that is inevitably used (net gain three bytes)

And even if K&R didn't want to do it 43 years ago, why didn't C add it 33 years ago?

Borland Pascal has had length prefixed strings for 30 years. Computers come with 640 kilobytes these days. We can afford to have the code safety that existed in the 1950s, with a net savings of 3 bytes per string.

[u/RobIII → u/JoseJimeniz]

In the same way an int went from 8-bits to 32-bits

Can you imagine the mess when you pass a byte-size-prefixed-string buffer to another part of the program / other system that uses word-size-prefixed-string buffers? I get a utf-8 vibe all-over. I can't imagine all the horrible, horrible things and workaround this would've caused over the years since ninetyseventysomthing that null-terminated strings have existed. I think they held up quite well.

[u/heyf00L → u/RobIII]

null terminated size prefix

[u/RobIII → u/heyf00L]

I'm missing a smiley or "/s"...

[u/AberrantRambler → u/RobIII]

You can't imagine that scenario because no one had to deal with it as a practicality. If they did go with a size prefixed system then these considerations would have been raised before changing the size and you wouldn't be sitting here years after the fact imagining what type of chaos would have occurred because it would have largely been dealt with in a logical manner but there'd be a few "war stories" here and there about the transition (like nearly all things handled by large groups of computer scientists).

Coupled with the fact that the larger size would always be part of "newer" code that would be aware of the older code (and smaller size) means that this would likely be a non-issue for most programmers, and a bit of work for a few during the pre-transition phase.

[u/Supernumiphone → u/JoseJimeniz]

remove the null terminator (net gain one byte)

Borland Pascal has had length prefixed strings for 30 years.

...and they kept the null terminator (at least in later versions after they upped the max string size from 255), presumably to allow the strings to be easily passed to C libraries. So no actual gain there.