0

I am having an odd memory bug.

The code is simple:

void *to = calloc(2, sizeof(uint64_t));
... 
int add_symbol_to_symbol(void *from, void *to) {
  uintptr_t *fromSymbol;
  uintptr_t *toSymbol;
  uint64_t    i;

  fromSymbol = (uintptr_t*) from;
  toSymbol = (uintptr_t*) to;

  for (i = 0; i < 2; i++)
  {
    *toSymbol ^= *fromSymbol;
    toSymbol++;
    fromSymbol++;
  }

  return 0;
}

When I debug the code and print out the addresses of the memory and the value of that memory, I can see that toSymbol has non-zero values in its memory before the xor occurs... but it depends on how I print out the data.

gdb:

print toSymbol
$21 = (uintptr_t *) 0x650400
(gdb) print (toSymbol+1)
$23 = (uintptr_t *) 0x650408
(gdb) print *(toSymbol)
$25 = 0
(gdb) print *(toSymbol+1)
$24 = 4575657221408423936
(gdb) print *(unsigned long long)(toSymbol+1)
$26 = 0
(gdb) print *(unsigned long long*)(toSymbol+1)
$27 = 4575657221408423936
print *(uintptr_t*)(0x650408)
$30 = 4575657221408423936
(gdb) print *(uintptr_t)(0x650408)
$31 = 0

So my questions:

  1. Why does print (uintptr_t)(0x650408) display garbage data?
  2. Why does print *(uintptr)(0x650408) display a zero? (I.e., why does casting a 64 bit hex address to be a 64 bit value instead of a 64 bit address change anything at all!?!)
chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256
arinmorf
  • 1,374
  • 16
  • 27
  • Why are you using `void *`? Fix the type and things might be easier – Ed Heal Apr 05 '15 at 15:09
  • I'm trying to maintain compatibility with another library which expects all void*. I feel like the void* is what is killing me, but I don't understand WHY. – arinmorf Apr 05 '15 at 15:30
  • Surely the other library that wishes to hide the underlying data structures will also provide a mechanism to create those void pointers – Ed Heal Apr 05 '15 at 15:33
  • Why allocated with `uint64_t`, yet de-reference to type `uintptr_t`? Recommend `void *to = calloc(2, sizeof(uintptr_t));` – chux - Reinstate Monica Apr 05 '15 at 15:55

0 Answers0