Behavior of malloc (1) in C

Neither. malloc allocates the memory area, but does not clear it. Therefore, any content that was abandoned there will continue there (this content is affectionately called garbage ). So the content of the pointer after malloc can be anything because it contains garbage.

It is recommended to write something in the allocated memory to prevent you from accessing content that is garbage, which would probably make the program behave incorrectly.

If you call malloc(1) , a pointer that points to 1 byte of allocated memory will be returned. It may even be that malloc internally reserves a larger area for performance purposes, but the only guarantee that exists is that 1 byte of reserved memory will be returned to you (reserved but not cleaned), and that if you access beyond the limit (the second byte, in position 1), is accessing an area of non-reserved memory (which can cause segmentation to fail, access the contents of some other variable, or read or write junk somewhere).

Victor has already given the base answer to the question, I'll add that it's common for people to use a memset() to reset the memory when necessary. When needed calloc() can be used to allocate and zero. In theory it is possible to have optimizations, perhaps even in conjunction with the operating system to gain performance, but do not count on this, even because the c/re/malloc() " needs to be the original. The difference to malloc() is data cleansing.

In the case of interpreting the data as a string , and in C you can interpret as you wish, a 1 byte zeroed will be a string with 0 characters, the malloc() will be the string terminator .

In C it is not appropriate to cast cast from the result of char , this can hide errors, so what you want is just:

char *char_commandout = calloc(1);

But in general this does not make sense because you already know the content and it can not change in a useful and correct way, even if it needs a string of size 0, it is ideal to do this statically , even used the Flyweight .

Another curiosity that does not make the slightest sense is to use

malloc(sizeof(char))

It is guaranteed by specification that %code% always has size 1, in the background it is 1 byte. There are those who argue that one day can change, which is laughable, mainly because it is always said by an "experienced" programmer.

Usually allocations in heap over 8 bytes, even 16 make very little sense and in cases that does would be the case to rethink if it can do otherwise. In small things above the memory consumption to control the allocation is greater than the data itself. Of course it is not the only way to decide, there are things that need to be allocated indefinitely, but you can almost always avoid this. In practice, the allocation will be much larger than 1 byte, but you will only be able to access 1 byte, and if you try to access more than one before or after it, it will work, but for your own good, / p>