Unable to Acquire the Value of a Address that a Parameter Pointer has.

[Sinery]

I am unable to use * to acquire the value of the address that ReturnedArrayPointer has.
The comments in the code should explain in more clearly.

#include"Header.h"

/* These are in Header.h
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
*/


int Colour(ReturnedArrayPointer, ArraySize) 


// The call is this: Colour(ReturnedArrayPointer, ArraySize);


// Declared as: int *ReturnedArrayPointer = 0;


// ReturnedArrayPointer is given the first adress in my array before the call gets it here.


// ArraySize = 3.


{
    for (int i = 0; i < ArraySize; i++)
    {
        printf("\nSize: %d\n", ReturnedArrayPointer);
        
        // The value of the adressess are: 1, 2, and 3. In that order.
        
        // *ReturnedArrayPointer gives the error: Operand of '*' must be of a pointer.
        
        // So how do I display the value it's pointing at?
        
        printf("Size adress: %d\n", ReturnedArrayPointer); // Works as intended.


        ReturnedArrayPointer += 1 * 4;


        printf("Colour: %s\n", ReturnedArrayPointer); // I have no idea why this provides the value of the adress.
        printf("Colour adress: %d\n", ReturnedArrayPointer); // And that this works as intended.


        ReturnedArrayPointer += 8 * 4;
    }
    
    getch();
}

Running this part gives:


I'm using MVS Express 2013 and the C++ compiler (and .c source files).
OS: 64 bit Win7.

Thank you for your time.

[Aslaville]

Have you tried this

printf("\nSize: %d\n", *ReturnedArrayPointer);

[Sinery]

Have you tried this

printf("\nSize: %d\n", *ReturnedArrayPointer);

Yeah, that's when I get the Operand of '*' must be of a pointer error.

[Salem]

Perhaps if you put proper types in your function declaration, then the compiler would know what type it was.

At the moment, it seems that it's just defaulting to being an int type.

[Sinery]

Perhaps if you put proper types in your function declaration, then the compiler would know what type it was.

At the moment, it seems that it's just defaulting to being an int type.

Putting * in the function parameter gives me "Unamned prototyped parameters not allowed when body is present." error.

[laserlight]

Putting * in the function parameter gives me "Unamned prototyped parameters not allowed when body is present." error.

What is the type of ReturnedArrayPointer and ArraySize? For example, if ReturnedArrayPointer is a pointer to int and ArraySize is an int, then you would write:

int Colour(int *ReturnedArrayPointer, int ArraySize)

[Sinery]

What is the type of ReturnedArrayPointer and ArraySize? For example, if ReturnedArrayPointer is a pointer to int and ArraySize is an int, then you would write:

int Colour(int *ReturnedArrayPointer, int ArraySize)

I'll give you the whole life length of each.

int ArraySize = 3;
int *ReturnedArrayPointer = 0;

int Stock(ArraySize)
{
struct MyStruct *ArrayPointer;
ArrayPointer = malloc(sizeof(*ArrayPointer) * ArraySize);
return ArrayPointer;
}

ReturnedArrayPointer = Stock(ArraySize);

Colour(ReturnedArrayPointer, ArraySize);

And there's the call to the function.

I tested the ReturnedArrayPointer in the same function as the Colour() call is, and there the pointer works just fine.

[laserlight]

Well, that matches my guess, so you can apply my example in your actual function definition (and prototypes).

[grumpy]

A round-trip conversion (converting a pointer to an int, and then converting the int back to any pointer type) is not guaranteed to produce a usable pointer. The result of then using the pointer is undefined behaviour.

You haven't provided enough information, but what you have provided looks like
1) Stock() allocates a pointer to a struct, and returns it as an int
2) The assignment "ReturnedArrayPointer = Stock(ArraySize)" converts the int returned by Stock back into a pointer to int.

Hence you have such a round trip. You might get lucky and it will work sometimes. But, fundamentally, you should not be relying on conversions working in this case.

Even converting a pointer from one non-void type to another is not guaranteed to produce a useful pointer. But the round-trip conversion via an int does that in spades.


If you turned up compiler warnings, your compiler would have lavishly given you warnings on your code. The warnings would indicate the problem too.

[Sinery]

A round-trip conversion (converting a pointer to an int, and then converting the int back to any pointer type) is not guaranteed to produce a usable pointer. The result of then using the pointer is undefined behaviour.

You haven't provided enough information, but what you have provided looks like
1) Stock() allocates a pointer to a struct, and returns it as an int
2) The assignment "ReturnedArrayPointer = Stock(ArraySize)" converts the int returned by Stock back into a pointer to int.

Hence you have such a round trip. You might get lucky and it will work sometimes. But, fundamentally, you should not be relying on conversions working in this case.

Even converting a pointer from one non-void type to another is not guaranteed to produce a useful pointer. But the round-trip conversion via an int does that in spades.


If you turned up compiler warnings, your compiler would have lavishly given you warnings on your code. The warnings would indicate the problem too.

Yeah, I wouldn't be throwing a pointer all around the place if I wasn't instructed to do just that.

However, the pointer works just as it ought to all the way except at the place I showed above.
Below "ReturnedArrayPointer = Stock(ArraySize);" the pointer works just fine.
I just when it's sent with Colour(ReturnedArrayPointer, ArraySize); it doesn't want to play anymore.
And it does produce the correct addresses, I just don't want to give me one of the values.

[grumpy]

Yeah, I wouldn't be throwing a pointer all around the place if I wasn't instructed to do just that.

Then you need to work out a way that doesn't involve multiple conversions that can change the value.

However, the pointer works just as it ought to all the way except at the place I showed above.
Below "ReturnedArrayPointer = Stock(ArraySize);" the pointer works just fine.

You're just getting lucky - or unlucky, in the sense that it makes you think it works when there is no such guarantee. That is not guaranteed to work.

I just when it's sent with

Colour(ReturnedArrayPointer, ArraySize); it doesn't want to play anymore.
And it does produce the correct addresses, I just don't want to give me one of the values.

The thing is, when you do invalid conversions, the result is NEVER guaranteed to be usable. However, practically, it sometimes works - depending on how your compiler does things under the hood.

When you do multiple invalid conversions, you're just playing against the odds more, and increasing the chances that something will go wrong (i.e. increasing the chances of encountering a problem because your compiler doesn't do things under the hood in the way you need).

What you need to do is find a way to do valid conversions, so the pointer survives the process in a usable state. Preferably in a way that doesn't rely on your compiler vendor doing things they don't have to. That will not involve using an int as an intermediate value. Ever.

[Sinery]

Then you need to work out a way that doesn't involve multiple conversions that can change the value.

You're just getting lucky - or unlucky, in the sense that it makes you think it works when there is no such guarantee. That is not guaranteed to work.



The thing is, when you do invalid conversions, the result is NEVER guaranteed to be usable. However, practically, it sometimes works - depending on how your compiler does things under the hood.

When you do multiple invalid conversions, you're just playing against the odds more, and increasing the chances that something will go wrong (i.e. increasing the chances of encountering a problem because your compiler doesn't do things under the hood in the way you need).

What you need to do is find a way to do valid conversions, so the pointer survives the process in a usable state. Preferably in a way that doesn't rely on your compiler vendor doing things they don't have to. That will not involve using an int as an intermediate value. Ever.

The task I have is required to have a pointer as a return value, and then use a pointer that is pointing on the same address as a parameter to another function where it will go through the array.

I don't know if it's possible to return the pointer any safer way than I am already doing.

[laserlight]

Ugh, my bad. Why aren't you just working with pointers to struct MyStruct?

[Sinery]

Ugh, my bad. Why aren't you just working with pointers to struct MyStruct?

Frankly, this is the first time I'm using a struct and there is little instruction on how I shall use it, so I have no idea if I am utilizing it as I should.

[grumpy]

Why can't you specify a return type of Stock to be the type "struct MyStruct *"?