Increment pointer address and value in C

Question

int main (void){
    int num1=2;
    int *pnum=NULL;
    pnum=&num1;
    *pnum++;
    printf("%d",*pnum);
    
}

why does this code print the address, not the value? Doesn't * dereference the pnum?

Answer 1

Check the precedence of operators: postfix unary operators bind tighter than prefix unary operators, so *pnum++ is equivalent to *(pnum++), not to (*pnum)++.

pnum++ increments the pointer pnum and returns the old value of pnum. Incrementing a pointer makes it point to the next element of an array. Any variable can be treated as an array of one element, so pnum points to the element after the first in the one-element array located where num1 is, which I'll call num1_array[1]. It is valid for a pointer to point to the end of an array, i.e. one position past the last element. It is not valid to dereference that pointer: that would be an array overflow. But it is valid to calculate the pointer. Constructing an invalid pointer in C is undefined behavior, even if you don't dereference it; however this pointer is valid.

*pnum++ dereferences the old value of pnum. Since that was a pointer to num1, this expression is perfectly valid and its value is the value of num1. At this point, any halfway decent compiler would warn that the value is unused. If you didn't see this message, configure your compiler to print more warnings: unfortunately, many compilers default to accepting bad code rather than signal the badness. For example, with GCC or Clang:

$ gcc -Wall -Wextra -Werror a.c
a.c: In function ‘main’:
a.c:6:5: error: value computed is not used [-Werror=unused-value]
    6 |     *pnum++;
      |     ^~~~~~~
cc1: all warnings being treated as errors

The call to printf receives the argument *pnum. We saw before that at this point, pnum points to the end of the one-element array num1_array[1]. This pointer is valid, but since it points to the end of an object, dereferencing has undefined behavior. In practice, this usually either crashes or prints some garbage value that happens to be in a particular memory location. When you're debugging a program, there are tools that can help by making it more likely that an invalid pointer will cause a crash rather than silently using a garbage value. For example, with GCC or Clang, you can use AddressSanitizer:

$ export ASAN_OPTIONS=symbolize=1
$ gcc -Wall -Wextra -fsanitize=address a.c && ./a.out 
a.c: In function ‘main’:
a.c:6:5: warning: value computed is not used [-Wunused-value]
    6 |     *pnum++;
      |     ^~~~~~~
=================================================================
==2498121==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff15ae3e74 at pc 0x55d593978366 bp 0x7fff15ae3e30 sp 0x7fff15ae3e20
READ of size 4 at 0x7fff15ae3e74 thread T0
    #0 0x55d593978365 in main (/tmp/stackoverflow/a.out+0x1365)
    #1 0x7f525a1380b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #2 0x55d59397818d in _start (/tmp/stackoverflow/a.out+0x118d)

Address 0x7fff15ae3e74 is located in stack of thread T0 at offset 36 in frame
    #0 0x55d593978258 in main (/tmp/stackoverflow/a.out+0x1258)

  This frame has 1 object(s):
    [32, 36) 'num1' (line 3) <== Memory access at offset 36 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/tmp/stackoverflow/a.out+0x1365) in main
Shadow bytes around the buggy address:
  0x100062b54770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100062b54780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100062b54790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100062b547a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100062b547b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100062b547c0: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1[04]f3
  0x100062b547d0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100062b547e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100062b547f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100062b54800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100062b54810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==2498121==ABORTING

This trace tells you:

• That there was a buffer overflow in a local variable (stack-buffer-overflow).
• That the overflowing access was an attempt to read 4 bytes (READ of size 4).
• Some more information about the problematic address ([32, 36) 'num1'). You can see that the program tried to access memory just after num1.
• The address of the problematic instruction (#0 0x55d593978365). You can set a breakpoint there in a debugger to examine what the program might be doing.

On most platforms, given your program, num1 is a variable on the stack, and the end of num1 is the address of the previous variable on the stack. This could be anything, depending on the details of how your compiler accesses memory. One of the many things this could be is pnum, if pnum and num1 happen to have the same size on your platform (this is typically the case on 32-bit platforms) and the compiler decides to put pnum just before num1 on the stack (this depends heavily on the compiler, the optimization level, and fine details of the program). So it is plausible for your program to print the address of pnum: not because *pnum somehow didn't invoke the dereference operator, but because your program has made pnum point to itself.

Answer 2

When you write *pnum++; There, you change the address pnum is pointing. And incrementing it by one, we don't really know where it has started to point. As suggested above, it's referencing garbage right now.

Answer 3

You need to put parenthesis around *pnum. Otherwise the address which the pointer points to is changed. pnum++ is pointer arithmetic and increments the pointer by the number equal to the size of the data type for which it is a pointer, in this case sizeof(int). This means it doesn't point to the correct value anymore and the program therefore prints “garbage” as mentioned by Eugene Sh. in the comments, because it dereferences the incremented pointer using *(pnum++).

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    int num1 = 2;
    int *pnum = &num1;
    (*pnum)++; /* important */
    printf("%d\n", *pnum);

    return EXIT_SUCCESS;
}

Answer 4

Postfix operators always have higher precedence than prefix operators in C. So *pnum++ is equivalent to *(pnum++) -- it increments the pointer, not the value pointed at.

You need (*pnum)++ or ++*pnum if you want to increment the pointed at value.