Is it good practice to return a pointer from a function in c?

Question

For Ex:

int *point() { int *q = malloc(sizeof(int)); *q=20; return q; } int main() { int *a = point(); free(a); } 

I wonder is this a good practice in c?

Answer 1

Returning pointers are pretty common. The task or need for discipline is to make sure where the responsibility for freeing the memory lies. This example smells because it is not clear that it should be free in main ().

Answer 2

I think the problem is free (a); I think you should add the release_point () function.

Answer 3

See sample C on the wikipedia page for opaque pointers . This is a way to structure code where you completely manage memory on one side of the interface.

Answer 4

The only real danger that I know with returning a pointer to allocated memory is this: if your library is compiled on Windows and linked to one instance of the Visual C ++ Runtime Library (MSVCRT), for example, it is statically linked to it and the client program is linked to another instance, for example, it is associated with a DLL, then each of them has a different malloc arena, and the pointers returned by the library cannot be freed by the program. Any attempt to do this may cause the program to crash.

Answer 5

I would always protect your own function to free the memory that your library returns if you do not return something trivial, such as a string.

The reason for this is that if you change the structure of what you return, so that there will no longer be free (because you add objects to the allocated memory that should be freed), the clients will not need to change their code ; you can simply modify an existing free function.

Thus, the presence of your free function isolates clients from the structure of objects returned by your library, leaving the ability to change the structure of your objects without affecting clients.

Answer 6

If you have a sequential system, knowing which functions return pointers that should be freed up (for example, using the word create or new in a function name), this simplifies the management of your memory.

 int *createPoint() { int *q = malloc(sizeof(int)); if (*q) *q = 20; return q; } 

Answer 7

This is often a good practice, but your example is one of the few times when it is a very bad practice. You should never use dynamic allocation and pointers for individual objects that are small and do not (and never will) contain pointers themselves. Getting a 4-byte int with malloc uses at least 16 bytes if you consider the overhead of bookkeeping, but perhaps more importantly, that means you need to worry about possible distribution failures (and how to handle them) and manage when releasing an object.

Some examples of objects that you should not highlight as follows:

• any basic type
• ordered pairs / coordinates / vectors / matrices / etc. (if they are fixed)
• ip addresses
• color values

Of course, once it would be advisable to select and return a pointer to such objects when you select an array from them.