Char pointer or char array?

Question

There’s a program that I picked up at a company, where pointers are used to char, guy char*, and then allocated a memory for it with the malloc, done the operations and at the end de-located that memory. It normally receives all characters, up to the maximum size.

A array of char can perform better or more safely? Type control the maximum size you can receive, memory overflow, etc.

{
char* x;
x = (char*)malloc(16*sizeof(char));
x = (char*)NULL //aparentemente é pra alocar uma memória limpa
func(INPUT y, OUTPUT x);

free(x);         //aqui ele
x = (char*)NULL; //limpa a variável
}//essa é o tipo de função que eles usaram

{
char x[16];
memset(x,'\0',strlen(x)); //também é pra ter uma memória limpa
func(INPUT y, OUTPUT x);

memset(x,'\0',strlen(x)); //limpa a variável
}//essa seria a mesma função só que com um array de char

Answer 1

The array of char can give better performance, after all will avoid a dynamic allocation of memory, which is something relatively expensive. No matter if the size will be determined at build or run time.

In the example of the question it would be better to use this form, but not always this is possible.

Safety and reliability

Security is always achieved by knowing what you are doing, understanding how the computer works, how the language works, the details of the API you are using, etc. The use of array in place of dynamic allocation neither helps nor harms security directly. There is nothing in a resource or other that prevents the overflow of memory usage. In C it is a programmer’s problem to treat this.

The use of dynamic memory is usually less reliable. Not by itself, but because programmers tend to err more in their use, and what is not so reliable may be less safe, but it is something indirect.

When to use

Normally the allocation of array is made in the stack - so it’s fast - which doesn’t allow you to have a array much large (much less if the size cannot be determined in the compilation or at least guaranteed that it will not be too large), nor that it survives at the end of a function (or scope), so there are cases that the allocation in the heap - with malloc() - is the only viable solution.

Even in cases of allocation being in a structure, it can make it too big, and it is not always what you want, mainly because it would practically require your allocation in the heap (dynamic allocation), which is not always desirable.

Basically the difference between the array and dynamic allocation is really only in allocation, one offers no more resources than the other. Once allocated, it gives in the same, the language does not differentiate one from the other.

The default is always to use the simplest form, which is the allocation of array, unless there’s a reason to dynamically allocate. This is not premature optimization, on the contrary, dynamic allocation should be avoided whenever possible, whenever it does not bring specific problems. It is simpler, more reliable and faster, only has advantages when what it needs will not be limited by its characteristic.

Completion

Looking up, overall this code is poorly written and does not meet modern standards. Apparently it may have been written by those who do not yet know the right language, even by other errors.

See more about the decision (is C++, but essentially the same thing).

Answer 2

In the part of the two codes, the type function they used is even wrong, so it would be an easy choice by the second type.

Using that line right after malloc is an error:

x = (char *)NULL //sem ";" ainda por cima...

Opinion considering that the two sections work: Varies greatly according to the case.

Dynamic allocation is usually advantageous in performance and memory if there are large fluctuations of objects. You don’t need to keep 256 positions allocated if you usually use 3 or 4. The bad part is that it’s usually more complicated to manage.

Even more so if you are to implement automatic security, the performance between the two will be changed. Only nowadays, the hardware usually allows programmers to have these "mimes". You have to see why this legacy code is so, changing all the code now would be silly too if it is too big and difficult to test.

That said, nowadays it is worth leaving optimization as one of the last priorities when programming. If the code will start to be created now, preferably clarity and ease of maintenance. Then, if you notice that some method needs performance, then you can look for where to squeeze.