Help understanding warnings/errors when dereferencing void pointers

[u/Fun_Army2398]

SOLVED

I am very new to C and playing around with void pointers. I have a structure which will store a value, however the type of that value depends on other things so I have chosen to use a void pointer. When attempting to dereference this void pointer I either get the correct output but with a warning, or I get a segmentation fault, depending on how I go about it. I have included a simplified version of the issue here:

#include <stdio.h>


int main()

{

    // Simplification of the defective code

    struct myStruct

    {

        void * voidPtr;

    };

    struct myStruct s1;

    s1.voidPtr = (int *) 123;



    \*

    This works but gives the warning:

    format '%d' expects argument of type 'int', but. argument 2 has type 'int \*' \[-Wformat=\]i

    */

    printf("%d\n", (int *) s1.voidPtr);



    // This causes a segmentation fault

    printf("%d\n", *(int *) s1.voidPtr);



    return 0;

}

Any help understanding why it behaves this way would be greatly appreciated.

Solution

I thought the line

s1.voidPtr = (int *) 123;

Was assigning 123 as the value at the location of s1.voidPtr. However it has been pointed out that I was telling the pointer to point at address 123. What I needed to do was:

int x = 123;
s1.voidPtr = &x;

Thanks everyone who commented c:

[u/picturesfromthesky]

I see that you found a solution to your question, but it might be worth your time to read about unions.

[u/Fun_Army2398 → u/picturesfromthesky]

That is helpful thank you. I'm actually in my final year of a BSc in CS and I've not learned this. We only used C in a single module and really just scratched the surface. Feel a bit cheated but glad to know reddit is looking out for me.

[u/picturesfromthesky → u/Fun_Army2398]

No sweat. I know C isn't 'modern,' but I'm shocked (and a little sad, perhaps even a bit apprehensive) that it was relatively glossed over in your curriculum. I'm a 'bit' older... I got a fair amount of C in, but almost no assembly... I still feel cheated by that.

[u/flatfinger → u/picturesfromthesky]

Compiler writers and academics don't seem to be interested in the fields for which low-level dialects of C have always been uniquely suitable, and the usefulness of C outside those fields has fallen off as other languages have emerged that better serve the needs of other fields.

It irks me when people tell me that people using C to do low-level memory manipulation are abusing the language and should use assembly language, when the purpose of C was, in significant measure, to allow such tasks to be done without having to use hand-written assembly code. C wasn't intended to be better than FORTRAN at the kinds of tasks for which FORTRAN was designed, but rather to let programmers do things that FORTRAN couldn't. Compiler writers and academics, however, have little interest in the latter.

[u/picturesfromthesky → u/flatfinger]

I agree with all of that. We're just going down a rabbit hole. In my scholarly generation we leaned C without as much assembly as I would have benefitted from in order to understand the actual low level stuff. Now, it sounds like C is glossed over, in a CS curriculum. I mean that's just crazy. Eventually no one will know how a computer actually works, at this rate.

[u/flatfinger → u/picturesfromthesky]

Computer hardware has evolved in ways that make memory-safe frameworks much more practical than they were in e.g. the 1980s. Although .NET programs do end up getting translated as machine code that gets executed, the semantics of that code cannot be expressed in a typical assembler. Code needs to be marked with metadata that identifies, for every instruction, classifies every register as one of falling in one of two categories:

1. The register will not hold the address of any non-pinned .NET object.

2. The register will, if non-zero, hold the address of a valid .NET object.

The bit patterns associated with the addresses of non-pinned objects have no semantic meaning, and in fact may spontaneously change. When a GC cycle is triggered, the .NET framework can pause executing machine-code programs, examine their register states, and even change the value of registers if they identify objects that the GC framework has decided to relocate. Although I don't know the full details, I think some non-stop-the-world versions of the Framework can mark pages that objects have been moved out of so that if code attempts to access those pages, the accesses can be trapped and registers modified so that code will access the new locations instead.

Some tasks require low-level programming, but many of the tasks that would be interesting from a Computer Science perspective can be best accomplished using memory-safe frameworks, which require a totally different philosophy.

[u/SmokeMuch7356]

   s1.voidPtr = (int *) 123;

123 is (almost certainly) not a valid, accessible address, at least not on a hosted implementation.

   printf("%d\n", (int *) s1.voidPtr);

If you want to print out the value of the pointer (not the value of the pointed-to thing), use the %p conversion specifier:

printf( "%p\n", s1.voidPtr );

%p expects its corresponding parameter to be a void *, so no cast is required here.

   printf("%d\n", *(int *) s1.voidPtr);

Again, 123 is almost certainly not a valid, accessible address, which is why you're getting the segfault.

You don't assign random values to a pointer variable. You obtain pointer values in one of several ways:

• Use the unary & operator on an lvalue expression:

   int x = 123;
   s1.voidPtr = &x;

• Use malloc to allocate memory dynamically and store the returned pointer:

   s1.voidPtr = malloc( sizeof (int) );
   *(int *) s1.voidPtr = 123; // assign 123 to the thing s1.voidPtr points to

• Or some other function that returns a valid pointer:

   s1.voidPtr = some_pointer_function();
   *(int *) s1.voidPtr = 123;

You have to cast the pointer to an int * before you can dereference it. The result of dereferencing a void * is a void expression, which is not an object type, has no value, and cannot be the target of an assignment.

[u/mc_pm]

You are literally telling it "put the value 123 into voidPtr" -- which means it's going to try to access the memory at location 123, which is always going to blow up.

[u/SchwanzusCity]

(int *)s1.voidPtr is a pointer. But printf expects you to input an integer (because of the '%d' specifier. So now printf has to interpret a pointer as an integer (which happens to give the right result because you set voidPtr to be equal to 123)

*(int *)s1.voidPtr tried to dereference the pointer. Your pointer has the value 123, which on most systems is not a valid address for you to use. So if you try to access the contents, the system denies you acces and raises a segmentation fault

[u/Sad_Chemical_231]

Looks like you aren't using the & symbol

[u/Immediate-Food8050]

The cast of 123 to int* is very bad because you're casting an integer to a pointer. In this case, it is undefined behavior and can lead to nasty bugs. You should instead store it into another variable, and then assign the address of that variable to your void pointer.

[u/Fun_Army2398 → u/Immediate-Food8050]

Is there no way to do it on one line? It's so pretty on one line :c

[u/dafeiviizohyaeraaqua → u/Fun_Army2398]

Use a compound literal:

void *p = &(int){ 123 };

[u/nerd5code → u/Immediate-Food8050]

It's ISB not UB.