pointer + size does not really fix anything, as you are relying on the programmer to correctly keep track of the size. I'm not even sure what alternative this improves upon. even more error-prone null value marking the end? praying the array will be big enough (looking at you, gets!)?

unless you have a team of incredibly diligent coders, people are going to read past the end of bare arrays over and over again. one specific mistake I keep seeing is where people misinterpret the meaning of a variable named `size`. is it the number of elements or the size in bytes? who knows, but it's probably UB either way if you're wrong.

> misinterpret the meaning of a variable named `size`

Quite right. I use, and highly recommend, the convention that `size` is for number of bytes, `length` is for number of elements, and `capacity` for the allocated number of elements.

    assert(length * sizeof(element) == size);
    assert(length <= capacity);

Would you just wrap the pointer and size in a strut, then only iterate the array via a library of functions that check the size first?

I don't code c full time, but it's what I have always done when needing to use c via ffi to get a speed up in a dynamic language.

you could do that, if you were using a library that provided/understood that struct. not sure how common this is; I work with c++ much more than c.

the problem with this approach is that you are still relying on the application programmer to provide the correct size at the beginning and not to mess it up by directly accessing the struct member later. private/public does not really exist in c, so it is a lot harder to enforce invariants within an object. the library could make the struct layout a private implementation detail (ie, not fully define the struct in the header provided to the client and take a pointer to the struct as arguments in the API) to at least discourage this. you could combine this approach with a my_array_struct_init function that returns a pointer to an empty array object. this is a common approach taken in c libraries (eg, libcurl) where the author really doesn't want you messing with their structs.

You can, but since C doesn't have templates or operator overloading this becomes awkward and unappealing.

But it makes it so much easier to

- Statically check the code, since the static analysis tool knows for certain which value is the size and can check that you're using correctly.

- Initialize the size correctly, since you don't have to enter it twice, or more crucially, remember to change it twice (or create a #define in another part of the file, name it, and document it)

You also make an excellent point yourself about the meaning of 'size'. If this was standardized, it would be the same everywhere, minimizing the risk of ambiguity.

"relying on the programmer to correctly keep track of the size"

I don't interpret Walter's suggestion that way. Of course, I might be wrong. Since the compiler must know the size of the array at the time it's declared, my thinking is that the compiler is smart enough to pass the size without the programmer having to even think about it.

Any production-quality C code?

Any or some? I'm not sure if I've seen that in the wild.