There's no abstraction or 'concept' of arrays there. You are literally just telling the compiler to take a certain pointer and move i steps ahead.
Or something. That analogy sounded better in my head than written down. The point is that IMO the blame lies squarely with the C language: it's a language that's used in a lot of complex parsing code and provides pretty much nothing to help with this, and if anything actually puts roadblocks in the way.
Are you aware that atoi("a"); is undefined behavior? It can crash, it can launch nethack, it can return 0.
If you outfitted a police force with guns without safeties and hair-pull triggers, and you have any sanity, you're not going to be surprised if the rate of accidental discharges goes up. Programmers use their programming languages a lot more frequently and with a lot less care.
So, sure, let's tell the programmers to be more careful. But the most careful of programmers know they'll still make mistakes, and seek out ways to aid themselves in catching those mistakes instead of hoping they can will them away. One such aid can be choosing another programming language that doesn't share C's language mechanics.
Put another way - programmer's mistake for choosing to use C's language mechanics. You could argue that's technically not saying it's the fault of C language mechanics, but I'd say that's splitting hairs at the best.
You could share the blame with a failure to properly fuzz, and insufficient use of static analysis. I'd be okay with that too.
so if you buy that car and you do that, it's your fault regardless of how poor the car design is
pretty sure trusting user provided data without validation is the programmers fault regardless of language
Excellent!
> it's in the manual
It's not in MSDN: https://msdn.microsoft.com/en-us/library/yd5xkb5c.aspx
It's not in the manpages: https://linux.die.net/man/3/atoi
Cppreference understates it has having an undefined return value, rather than undefined behavior outright: http://en.cppreference.com/w/cpp/string/byte/atoi
Tutorialspoint defines the behavior as returning 0, and fresh2refresh makes no mention of undefined behavior.
My eighth google hit for atoi finally, finally, gets it right: http://pubs.opengroup.org/onlinepubs/9699919799/functions/at...
If you buy or pirate a copy of e.g. the C89 standard, or refer to one of the free draft versions, it's of course properly documented there too. Neither shows up in the first 50 google results, naturally.
And, of course, by google result 9, we're back to square one - incorrectly defining the behavior as being "returning 0": https://en.wikibooks.org/wiki/C_Programming/stdlib.h/atoi
That's likely because having to pass it in and out of functions and libs that don't expect your special structure might cause it to have an invalid length, and then all your special wrappers can become a liability and not an advantage through either assuming your bufs are valid, or defensively checking more than is necessarily because they can't know whether it was altered or not.
> stdlib doesn't provide them either
Which is the real problem. That would make them a de facto standard, and a lot (but probably not all) of the problems would be mitigated by people accepting the performance trade offs needed to make them safe.
Actually we often give up features and specialize with high level languages. That's why there are things easier to do in Ruby than in C++ and vice versa.
They are all (usually much more convenient) subsets of assembly.
FRONT
TOWARD ENEMY
So IMO it's absolutely pointless trying to argue with them in the first place. They are set in their ways and while a good chunk of them are pretty strict and excellent in what they do, they are not open to any changes.
I would be the first to agree that Go and Rust aren't ready to start replacing drivers but IMO people should start trying! (Or invest in LLVM some more?)
C/C++'s faults aren't ever going away. They're too convenient in their target area. I am against the overly-used "disruption" term -- I happen to believe the USA tech blogosphere bastardized the term long ago -- but IMO the systems programming area is very, VERY overdue for disruption.
It's time.
However, arrays that are passed as arguments to functions decay into raw pointers, at which point you lose information about its length.
In C99 with rather spotty support. And never with malloc and similar, which is how the vast majority of arrays are (and can be) created. And you can't return or store those dynamic arrays somewhere else without losing the size info, nor it can be declared static.
In other words, you're right but for very limited situations.