I would make it impossible for a simple addition of two integers to result in undefined behaviour

Good news. Arrays have sizeof(arr)/sizeof(arr[0]) elements and strings have strlen(str) letters.

.. until you pass them as a function argument. And strlen() only works if your null terminator is valid, and doesn't tell you anything about available space in the string buffer for adding to the string.

This kind of thing keeps coming up in vulnerability reports.

This happens because people don't use the tools properly.

If different people keep chopping into themselves with a power tool it's probably wise to consider a safety guard.

Wrong is still wrong, and if someone did it, they did it wrong.

This really isn't complicated. It's hardly obscure. There's no excuse.

They should be using Ada instead of C, amiright /s

I have no way of knowing what they should use.

C arrays “know” their size. (String literals do too.)

You can sizeof them if the declaration is in scope. If you pass them as function argument, this information is not obtainable inside function. You have to pass length as well. This is not very elegant and sometimes you elect to process them without using functions just because you can iterate them easier.

So roll your own struct based solution to where the size is now state.

If you're talking about the old stdlib.h calls, don't use them with blind pointers where the size isn't known. I'd say use the "n" versions but you don't even have to do that.

'C' gets easier when you do faux RAII and make "objects" with internal state, at least think about not using dynamic allocation for everything and think a little bit about what might make the API usable by the extremely lazy.

Now, at one point, you stopped talking about arrays and started talking about pointers.

That's because C tosses out all of that array state information at the drop of a hat once you start passing them around to functions.

Worse, it's an easy way to get burned on the sizeof() function, especially if you at some point refactor the code and put that chunk in a function separate from the original declaration.

This is why C programmers get gunshy about relying on that information and instead just treat strings like pointers all of the time.

> This is why C programmers get gunshy about relying on that information and instead just treat strings like pointers all of the time.

Good programmers do nothing of the sort.

Exactly. When array is passed into function, you lose length information and array construct is reduced to pointer. Array syntax is just synthetic sugar for dereferencing pointer with offset.

This discussion won't get very far if all you think arrays are is syntactic sugar. The array type is useful - think in terms of a static analyser if it helps - in different ways than pointers.

"array syntax" != "arrays". He means things like a[i]. Arrays are only really arrays in their local scope, if you pass them to functions they suddenly are pointers (but for some insane reason, C compilers let you specify "the size of the array in a function argument" which doesn't actually compile to any code).