[Xin version of small programming question] Passing pointer as parameter?

辛昕

[Xin version of small programming question] Passing pointer as parameter? [Copy link]

 

The answer to this small programming question is very simple. However, the short conclusion behind it is worth pondering -

The parameter is passed in the form of a pointer (address), and the parameter can be modified. Then the question is, what if the value of the pointer is to be modified? Then - naturally, the pointer (address) of the pointer must be passed in.

Many times, because functions in most languages can only return at most one return value (except Go). So we often put more variables that we want to return in the formal parameter. This raises a question. We are too familiar with the common sense that passing an address into a formal parameter can modify the content pointed to by the address. Because when passing formal parameters, the address passing and pointer look too similar. So, including me, I believe that most people subconsciously equate pointers with addresses. So, when one day we want to modify the pointer itself, it is often difficult to remember This time we are passing a pointer to a pointer (a secondary pointer). The code below is a small function I wrote recently on EGE to support the compatibility of different color formats of images. The purpose of this function is briefly explained as follows: The image file is given in array form. Finally, due to the different RGB bit numbers, the offsets are different when they are taken point by point. RGB16 is 2 bytes, RGB24 is 3 bytes, and RGBA24 is 4 bytes. In order to pass the next read position, the function below passes the position of the next image array returned as a parameter because the return value is already occupied. [code]color_t get_pixel_color(uint8_t *pSrc,uint8_t *pNext) { uint8_t *p; if(ColorType == RGB32) { p = pSrc; pNext = pSrc + 4; return (EGERGB(*p,*(p + 1),*(p + 2) ) ); } else if(ColorType == RGB24) { p = pSrc; pNext = pSrc + 3; return (EGERGB(*p,*(p + 1),*(p + 2) ) ); } else if(ColorType == RGB16) { uint16_t rgb16; rgb16 = *(uint16_t *)pSrc; pNext = pSrc + 2; return rgb162color(rgb16); } else return (EGERGB(0,0,0) ); // This function uses a specific graphics library EGE, so please ignore some non-standard ANSI definitions and macros, which do not affect the problem at all.

辛昕

However, although the above function can be compiled, when it is actually run, it not only fails to achieve the original intention. It may even cause the array to cross the boundary and crash. Just treat this as a small programming question. It is actually not difficult and very simple, but it is a place that is not easy to notice. I wrote this function in this way at the beginning. It was not until I left the computer to take a shower after the error occurred that I thought of the problem. Then I thought of this problem. In fact, I have made this mistake more than once, so I specially brought it out to relieve everyone's boredom. The first person who gives the correct answer - briefly explain the reason and change it to the correct one based on this function, just post it. The moderator will transfer 100 core coins to you privately.

皈依

Waiting for the first friend to earn 100 core coins

辛昕

Guiyi posted on 2017-12-10 22:27 Waiting for the first friend to earn 100 core coins

shihuntaotie

Waiting for the first friend to correct

hljjxzhla

The function written by the OP should read the file image array continuously in a loop. At the same time, this function can perform three kinds of offsets: 2, 3, and 4 bytes. I guess the array out of bounds occurs because your loop count*4 is greater than the array length you defined. Maybe you should add a counter in the function to record your offset to prevent out of bounds. Waiting for the correct answer from the OP.

lcofjp

uint8_t **pNext

bobde163

rgb16 = *(uint16_t *)pSrc; pSrc is not half-word aligned when defined, access error?

cj_in

The correct answer on the 7th floor is to change only the value of the formal parameter.

yanhaijian

lcofjp posted on 2017-12-11 08:41 uint8_t **pNext

Your answer should be correct.

辛昕

lcofjp posted on 2017-12-11 08:41 uint8_t **pNext

That's how beautiful it is. 100 core coins are yours

hljjxzhla

Xin Xin posted on 2017-12-11 10:17 That's how beautiful it is. 100 core coins are yours

The parameter should be uint8_t **pNext, so you should use *pNext when using it in your function. I simplified your function and wrote a small example. I think it should be able to achieve the result you want. I hope we can discuss it.

• int test(int *present,int *next)
• {
• *next+=4;
• return (*present+*(present+1)+*(present+2)+*(present+3));
• }
• int main(void)
• {
• int i=0;
• int a1[3];
• const int a[12]={1,2,3,4,5,6,7,8,9,10,11,12};
• for(i=0;i<3;i++)
• {
• static int n=0;
• a1 [ i ]=test(&a[n],&n);
• printf("%d ",a1 [ i ]);
• }
• printf("\n");
• return 0;
• }

辛昕

hljjxzhla posted on 2017-12-11 08:36 The function written by the OP should read the file image array continuously in a loop. At the same time, this function can perform three kinds of offsets: 2, 3, 4 bytes...

This is also correct. The crash is just a small mistake unrelated to the topic. I recalled it and it was probably like this.

辛昕

hljjxzhla posted on 2017-12-11 18:24 The parameter should be uint8_t **pNext, so you should use *pNext in your function. I simplified your function and wrote a small example...

I don't quite understand the meaning of your implementation. What do you want to do?

hljjxzhla

Xin Xin posted on 2017-12-11 23:10 I don't quite understand the meaning of your implementation, what do you want to do?

Because I only saw the code of your function, I don't know how you use this function outside the function, but I guess your program should define two pointer variables (that is, the actual parameters assigned to the two formal parameters of your function). In the example I wrote, the address and subscript of the array element are directly taken to define one less pointer variable, eliminating the need to assign the value of the pointer of the next address to the current address pointer after calling the function. Of course, this is the case in C code. I don't know whether it is simpler or more troublesome after compiling. My level is limited and I can't understand assembly. To sum up, my idea is to simplify the code of calling functions. I don't know whether the execution efficiency has increased. Of course, I hope it can be increased, but I don't know how to check it. Experts who know about it can give me some advice.

辛昕

hljjxzhla posted on 2017-12-12 08:55 Because I just saw the code of your function, I don’t know how you use this function outside the function, but I guess your program should define two...

Oh, I called it like this. get_pixel_color(pimg,&pimg); Move the pointer on the same image. That is, move to the next pixel

辛昕

hljjxzhla posted on 2017-12-12 08:55 Because I only saw the code of your function, I don't know how you use this function outside the function, but I guess your program should define two...

I seldom read assembly. It's not optimization, not at that stage.