What’s the difference between an integer and a pointer?

3 Comments

1. 2018-09-25 3:06 pm

   Dr.Cyber

   A pointer points to some place in memory while an integer represents a number that does not point to some place in memory.
• 2018-09-25 6:57 pm

  Alfman verbose=1

  Dr.Cyber,

  A pointer points to some place in memory while an integer represents a number that does not point to some place in memory. [/q]

  I love this response

  Historically C developers have been able to take “pointer” and “integer” at face value, what they do and how they work is obvious to all of us. But GCC made a change that is quite unexpected and surprising. The article highlights one of these points of controversy:

  #include <stdio.h>

  #include <stdlib.h>

  int main(void) {

  int *x = malloc(4);

  *x = 3;

  int *y = malloc(4);

  *y = 5;

  uintptr_t xi = (uintptr_t)x;

  uintptr_t yi = (uintptr_t)y;

  uintptr_t diff = xi – yi;

  printf(“diff = %ld\n”, (long)diff);

  // int *p = (int *)(yi + diff); // diff == -96

  int *p = (int *)(yi – 96); // <— CHANGED!

  *p = 7;

  printf(“x = %p, *x = %d\n”, x, *x);

  printf(“y = %p, *y = %d\n”, y, *y);

  printf(“p = %p, *p = %d\n”, p, *p);

  }

  When run (on my Mac) it gives:

  $ clang-6.0 -O3 mem1d2.c ; ./a.out

  diff = -96

  x = 0x7ff21ac00300, *x = 7

  y = 0x7ff21ac00360, *y = 5

  p = 0x7ff21ac00300, *p = 7

  $ gcc-8 -O3 mem1d2.c ; ./a.out

  diff = -96

  x = 0x7fce5e400300, *x = 3

  y = 0x7fce5e400360, *y = 5

  p = 0x7fce5e400300, *p = 7

  Despite the fact that the variable contains -96 and the constant are clearly expressing the exact same operation and are mathematically identical, GCC treats them differently because they point to different structures.

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259

  [q]Here is a simpler example which illustrates this:

  /////////////////// test.c ///////////////////

  #include <stdio.h>

  #include <string.h>

  struct S

  {

  int x[1];

  };

  union U

  {

  struct S arr[64];

  char s[256];

  };

  int main()

  {

  union U u;

  strcpy(u.s, “abcdefghijklmnopqrstuvwxyz”);

  size_t len = strlen((char*)&u.arr[1].x);

  puts(len > 10 ? “YES” : “NO”);

  return 0;

  }

  //////////////////////////////////////////////

  This prints “NO” with -O1 and above. clang always prints “YES”.

  IMHO GCC’s behavior is just plain buggy, it even affects linux. I’m not alone in thinking that GCC made the wrong choice here, but GCC developers are defending their position because they argue that the official C language specification doesn’t specifically define what happens when you use addresses across different structure boundaries types, so they took the liberty of redefining the “obvious” mathematical operations on pointers that we all take for granted to do something else.

  While I understand that GCC is technically permitted to do anything in undefined parts of the spec, I vehemently disagree that GCC should do anything that violates the rule of least surprise. Memory management in C is already hard enough, the absolute last thing C developers need are new exceptions on how pointers work mathematically.

  Edited 2018-09-25 18:59 UTC
2. 2018-09-26 10:47 am

   RobG

   “In an assembly language we typically don’t have to worry very much about the distinction between pointers and integers.”

   That just means that in assembly you have to worry very much about the difference, confusing the two can lead to memory exceptions or worse security holes.

   A high-level language offers a degree of type-safety by separating the two concepts.