I think you're deliberately ignoring my point here.
Is it not part of the contract when you use C arrays that you have to keep track of their size?
You say this to me, but I can say that all the code dealing with them in the article can't do anything about the rule which causes C arrays to degrade to a pointer to the first element. If you want to work with C arrays, it is part of the contract that you know their size. You object to some of the easy to use answers on very silly grounds.Quote:
Well, the article's examples should probably be rewritten to loops doing stuff with the array. That makes more sense, but doesn't change the dangers of not knowing the array bounds.
Sticking to the example I picked out. It says,
So basically you have to know about the function to call it, but you can say this about any part of any program ever coded.Quote:
(to actually call the proper function to pass along the size; this may be a problem in larger projects where some programmer does not know of this function).
You even espouse the approach passing arrays as references before we ever hear that maybe C arrays aren't the right type. The problem is that this approach causes massive overloading based on type.
The array type, and its behavior in a majority of contexts, means that you should be writing functions that accept arrays of various sizes. It doesn't help to ruin a perfectly good function with nonsense like assert(size == 10); That's not going to work the second that the array is intentionally different. And a majority of the examples are contrived because of this reason; the article itself doesn't acknowledge how arrays are actually used in programs.
This article could be shortened considerably it admitted that C arrays were the wrong type in some places.