Char pointer or char array?

5

There is a program I took in a company where pointers of char , type char* , and then allocated a memory for it with malloc , done the operations and in the end deallocated this memory. Usually receives all characters, up to maximum size.

Can a array of char be better or more secure? 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,'
{
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,'%pre%',strlen(x)); //também é pra ter uma memória limpa
func(INPUT y, OUTPUT x);

memset(x,'%pre%',strlen(x)); //limpa a variável
}//essa seria a mesma função só que com um array de char
',strlen(x)); //também é pra ter uma memória limpa func(INPUT y, OUTPUT x); memset(x,'%pre%',strlen(x)); //limpa a variável }//essa seria a mesma função só que com um array de char
    
asked by anonymous 03.03.2016 / 14:21

2 answers

2

The array of char can give better performance, after all it will avoid a dynamic allocation of memory, which is relatively expensive. It does not matter whether the size will be determined at compile or run time.

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

Safety and reliability

Security is always obtained by knowing what you are doing, understanding how the computer works, how the language works, the details of the API you are using, and so on. Using array instead of dynamic allocation does not help or directly hamper security. There is nothing in one feature or another that prevents memory usage overflow. In C, it is a problem for the programmer to handle this.

Dynamic memory usage is often less reliable. Not by itself, but because programmers often err more in their use. And what is not so reliable may be less secure. But it's something indirect.

When to use

Normally, the array allocation is done in the stack a> - so it's fast - which does not allow for a large array (much less if the size can not be determined in the build or at least guaranteed that it does not it will be very large), nor that it survives the end of a function (or scope), so there are cases that the heap - with malloc() - is the only viable solution.

Even if the allocation is in a structure, it can make it too large, and it is not always what you want, mainly because it would almost oblige you to allocate it in (dynamic allocation) which is not always desirable.

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

The default is to always use the simplest form, which is the array allocation, unless it causes a reason to allocate dynamically. This is not premature optimization. On the contrary. Dynamic allocation should be avoided whenever possible, provided it does not bring specific problems. It is simpler, more reliable and faster, it only has advantages when what you need will not be limited by its feature.

Conclusion

Looking over, this code is generally misspelled and does not meet modern standards. Apparently it was written by someone who does not know the right language yet.

See more about the decision (it's C ++, but essentially the same thing).

    
03.03.2016 / 14:28
0

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

Using this line right after malloc is an error:

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

Considering that both passages work: It varies a lot according to the case.

Dynamic allocation is often advantageous in performance and memory if there are large object fluctuations. You do not need to have 256 allocated positions 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 going to implement automatic security, the performance between the two will be changed. But nowadays, hardware usually allows programmers to have these "treats." You have to see what the reason for this legacy code to be like, changing all the code now would be silly too if it is too big and difficult to test.

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

    
03.03.2016 / 14:27