Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pointers Are Complicated II, or: We need better language specs

ralfj.de

Post reply on HN
Print view View original

11–20 of 135 posts

Re: Pointers Are Complicated II, or: We need better language specs

#11

Post by gens »

Pointers are "just" integers (unsigned integers of a size, that is). Most languages treat them differently (C assigns them a type, and a stride with it), but that is usually on top of them being integers.

Pointers "point" to (are addresses to) bytes, as he said. If you want you can pack data to a resolution of a bit, and some languages help you do that as well.

You can also do whatever you want with pointers (in some languages, ofc), like do bitwise operations on them. Aliasing them can be useful as well, in more then one way.

Why not just get rid of pointers ? You know you can.

Also, a byte is 0 .. 255. The hardest problem; naming things, and off by one errors.

Re: Pointers Are Complicated II, or: We need better language specs

#12

Post by steveklabnik »

gens wrote: post #11

Pointers are "just" integers (unsigned integers of a size, that is). Most languages treat them differently (C assigns them a type, and a stride with it), but that is usually on top of them being integers. Pointers "point" to (are addresses to) bytes, as he said. If you want you can pack data to a resolution of a bit, and some languages help you do that as well. You can also do whatever you want with pointers (in some…

They are not always integers. See this comment from the previous discussions on the other posts, for example: https://news.ycombinator.com/item?id=17607595

Re: Pointers Are Complicated II, or: We need better language specs

#14

Post by gizmo686 »

samatman wrote: post #10

Excellent article. It seems to me (and this is somewhat off-the-cuff) that compilers have another option: integers which are cast from pointers have provenance. That is, provenance is a taint: you can't clean it off through casting. So casting from pointer means the user can do integer-things like addition, but it means the compiler can't do integer-things like constant folding.

I don't think that works. Consider the following (contrived) program:

  char* q[1] = {0};
  int iq = (uintptr_t)q;
  int ip = 0;
  while (iq>0) {
    iq--;
    ip++;
  }
  char* p = (char*) ip;
You can make this more efficient (albeit no less contrived) by iterating through iq bit-wise.

Less contrived would be sending a pointer through some IPC mechanism (allowing it to be used as an opaque handle externally, while the program will blindly dereference it when it is passed back in); or even passing it within a program across compilation units.

If you treat provenance like a taint, you need to track every way it could be propagated, and that does not seem solvable.

Re: Pointers Are Complicated II, or: We need better language specs

#15

Post by TrianguloY »

I'm sorry but I don't fully understand the problem and that 'provenance' thing. For me the third optimization is the wrong one, for the same reason as this

  char i,j='0';
  *(&i+1)='1';
  cout
can't be optimized to

  cout
even though the j variable is also never overwritten directly.

This reminds me of paralelization of nested loops with pragmas, where you need to specifically say that two pointers will never point to the same space, otherwise the compiler won't optimize the loop because 'it could happen'.

Re: Pointers Are Complicated II, or: We need better language specs

#16

Post by pierrebai »

The bug is clearly the writing past the end of an array. That is:

    *(p+1) = 10;
If you start with a buggy program, that it stays buggy after optimizations is not surprising!

Edit: what;s more, the original form of the program also did not write through the q pointer and could have had optimizer the print zero. In the first form, the author assumes the compiler can track the pointer q through q == qi and avoid the optimization that would print zero, but fail to track pointer q through pi + 1 == qi == q.

Re: Pointers Are Complicated II, or: We need better language specs

#17

Post by mskslal »

pierrebai wrote: post #16

The bug is clearly the writing past the end of an array. That is: *(p+1) = 10; If you start with a buggy program, that it stays buggy after optimizations is not surprising! Edit: what;s more, the original form of the program also did not write through the q pointer and could have had optimizer the print zero. In the first form, the author assumes the compiler can track the pointer q through q == qi and avoid the opti…

No, the original program writes through iq, which is well defined. Only the optimized program writes through p+1.

Re: Pointers Are Complicated II, or: We need better language specs

#18

Post by Someone »

TrianguloY wrote: post #15

I'm sorry but I don't fully understand the problem and that 'provenance' thing. For me the third optimization is the wrong one, for the same reason as this char i,j='0'; *(&i+1)='1'; cout can't be optimized to cout even though the j variable is also never overwritten directly. This reminds me of paralelization of nested loops with pragmas, where you need to specifically say that two pointers will never point to the s…

If you think that, you’re giving up lots and lots of optimization opportunities.

There’s zero guarantee that i and j are adjacent on the stack or even on the stack (there isn’t even a guarantee that there is a stack, but that’s a different subject); a compiler can decide to keep j in a register. That is very common in short functions, and essential for performance.

It also would mean the compiler would have to load data from memory way more often, as ¿about? every pointer write might overwrite any memory.

Re: Pointers Are Complicated II, or: We need better language specs

#19

Post by gens »

steveklabnik wrote: post #12
gens wrote: post #11

Pointers are "just" integers (unsigned integers of a size, that is). Most languages treat them differently (C assigns them a type, and a stride with it), but that is usually on top of them being integers. Pointers "point" to (are addresses to) bytes, as he said. If you want you can pack data to a resolution of a bit, and some languages help you do that as well. You can also do whatever you want with pointers (in some…

They are not always integers. See this comment from the previous discussions on the other posts, for example: https://news.ycombinator.com/item?id=17607595

If 'b' is actually used then the compiler has to put 'a' in memory. Theoretically. He says that b is not changed, and does not "escape" (the scope of the code in question). In that case b is useless, and thus it doesn't really even exist. A compiler can "collapse" a lot of code into a fraction of it. That's a part of the "optimizing" part of "optimizing compiler". A compiler can put a value in a register. A compiler can do whatever it wants as long as the results are always the same as if it didn't do anything other then just translate to machine code.

Pointer aliasing in C can be bad for the compiler as it can't be sure that it can optimize away something. That's why Fortran is faster, and why the restrict keyword was added to the C standard.

And yea, i agree with him completely that a context should be made clear. Personally i'd like less voodoo in programming topics, but, on the other hand, this is still a young science and a lot of terminology is all around the place. ..Actually, scratch that, i found what i was interested in and don't really care about everything else.

Re: Pointers Are Complicated II, or: We need better language specs

#20

Post by sheepfleece »

TrianguloY wrote: post #15

I'm sorry but I don't fully understand the problem and that 'provenance' thing. For me the third optimization is the wrong one, for the same reason as this char i,j='0'; *(&i+1)='1'; cout can't be optimized to cout even though the j variable is also never overwritten directly. This reminds me of paralelization of nested loops with pragmas, where you need to specifically say that two pointers will never point to the s…

``` *(&i+1)='1'; ```

This line is UB, no? You are referencing some random, if adjacent, block of memory. Anything can happen.

Post reply on HN