C/C ++ returns the internal static member trap

Background

When we use C/C ++ for development, there is always a problem that will upset us. This problem is that the code inside and outside the function needs to interact with each other through a memory (for example, the function returns a string). This problem has plagued many developers. If your memory is allocated on the function stack, the memory will be released as the function returns, so, you must return a memory that is still valid outside the function.

This is a problem that has plagued countless people. If you are not careful, you are likely to make mistakes on this. Of course, there are many solutions. If you are familiar with some standard libraries, you can see a variety of solutions. In general, there are the following types:

1) allocate memory on the heap through malloc or new in the function, and then return the memory (because the memory allocated on the heap is globally visible ). This brings about potential memory problems. Because if the returned memory is not released, it is the memory Leak. Or is released multiple times, resulting in program crash. These two problems are quite serious, so this design method is not recommended. (In some Windows APIs, after you call some APIs, you must also call some of their APIs to release the memory)

2) let the user input a memory address of his own, and put the memory to be returned in the function into this memory. This is a common method. Many Windows API functions or standard C functions require you to input a buffer and the buffer length. This method should not be uncommon for us. The advantage of this method is that the program outside the function maintains the memory, which is simple and intuitive. But the problem is that it is a little troublesome to use. However, this method minimizes the chance of making mistakes.

3) The third method is quite different. It uses the static feature. Once the static stack memory is allocated, the memory will not be released as the function returns, it is globally visible (as long as you have the address of this memory ). Therefore, some functions use the static feature, that is, they do not need to use the memory on the stack, nor need to input a buffer and its length. In this way, your functions are very beautiful and easy to use.

Here, I want to discuss the third method. The method of using static memory seems good, but it has a trap that you cannot imagine. Let's use an actual case to give an example.

Example

People who have socket programming experience must know a function called inet_ntoa. The main function of this function is to convert a digital IP address into a string, this function is defined as follows (note its return value ):

Char * inet_ntoa (struct in_addr in );

Obviously, this function will not allocate memory on the heap, but it will not let you pass the buffer of the string into, so he must use the "return static char []" method. Before continuing our discussion, let's take a look at IP address-related knowledge. The following are the parameters that need to be passed in by the inet_ntoa function: (you may be surprised, what should I do if there is only one member struct in struct? This should be for future scalability of the program)

Struct in_addr {unsigned long int s_addr ;}

For IPV4, an IP address consists of four 8-bit bits, which are placed in s_addr. After the high position is reached, this is to facilitate network transmission. If you get an integer value of s_addr: 3776385196. Open your Windows calculator and see what its binary is? Let's start from right to left, with 8 digits in a group (as shown below ).

11100001 00010111 00010000 10101100

Then convert each group to decimal, so we get: 225 23 16 172, so the IP address is

172.16.23.225.

Now, let's get down to the truth. We have a program that wants to record the source address and destination address of the network package, so we have the following code:

Struct in_addr src, des;

................

Fprintf (fp, "source IP address <% s> t destination IP address <% s> n", inet_ntoa (src), inet_ntoa (des ));

<