Should the called function always check the array size in C? [closed]

Question

This is rather a question about programming style than about technicality: Should my C function always require an argument for the length of an array although the function is not dependent on it?

So either like this void foo(int* a, int size) or like void foo(int* a)

E.g. when the function just manipulates the first 128 bits of array, should the function require an array length and first of all check if the array is of the right length or should I trust the caller that he follows the documentation and only calls the function with the right size of the array?

I am new to C, so I fear something like an buffer overflow might be possible. A technical reasoning for why one is better than the other would be great. Thanks!

Answer 1

My rule is to differentiate between interface points and internal functions. Interface functions need to be paranoid and robust, but internal functions can assume that the caller knows what they are doing and can opt for efficiency over robustness.

Answer 2

A general rule should be to make errors known as soon as possible. You can have an error be caught at compile time, link time or run time or never be caught and have undefined behaviour.

Since you can check the size and produce a run time error, I would say that is better then have undefined behaviour if a user of your function passes a smaller array.

Of course sometimes speed is more important and that extra if will not be desired, then you have to relay that your users will read the documentation. That is how a lot of standard library functions are written. But this should be edge cases in your program. In general prefer to catch errors so you have less bugs in your code.

Answer 3

Good question, because you are trying to understand the intent behind the programming style / approach, before using it blindly.

Let me give you my perspective. A code is considered to be healthy, if it conforms to the following.

• If you are able to read & understand the code, without the need of comments.
• If your code is maintanable easily for future maintanence engineer without much difficulty.
• If you are able to add extensions to the original code, without changing the original code drastically
• If your code is closed / unaffected for the modifications in the set of inputs i.e your code solves all different variations of same use-case. Please refer Open/Closed principle.

The notion of including the length in the function signature, falls on the first 2 bullet points above.

As an author of a feature / logic, you know exactly what you are going to achieve and hence you don't want to add the length. However, think of case, some time later a bug comes in, and you are not there anymore in the project and someone else is taking over the role of maintenance. It will take considerable amount of effort for the engineer to make sense of what you had written and perform the fix.

While some argue that, they could write comments / have a low level documentation etc, it is not always a viable solution. The proper way is to follow a programming style that makes the code review intuitive and help future developers to contribute to the project at ease.

To sum-up, No, it not mandatory to provide a length, however it is always recommended to follow good coding guidelines to foster good ecosystem.

If you want to contribute to any of the opensource project, then you should embrace this concept for sure :-)

Good Luck!

Answer 4

Short answer: Yes, you should. :D Long answer: Since your array is actually a memory pointer, you cannot easily get the real size of it. So, if your function should modify the array data, it's wise to check if it can actually do it without overwriting memory that is not allocated to your array. It's generally a good practice to check memory limits before writing data to a pointer! ;)