3 ms·

Ehhhhh.... I can't help but think that it's never completely necessary to use totally unrestricted pointers in 'C'. Might be convenient, but very nearly certain

Ehhhhh.... I can't help but think that it's never completely necessary to use totally unrestricted pointers in 'C'. Might be convenient, but very nearly certainly not necessary. Even in systems calls and library functions, it's possible to never dereference a pointer in an unconstrained manner. But you have to be prepared to reason rigorously about those constraints. Noting that the semantics of array access semi-equate to pointer dereference is well beside the point. This fellow's "for" loop: for (int i=0; i < 20000) { for (int j=0; j < 20000) { x[i][j] = y[i-2][j+1] * y[i+1][j-2]; } } shows that you don't even have to have unrestricted pointer access to have bounds violations - what's "y[i-2]" when i==0? 'C' is not for everybody. It's a systems programming language. As the space of activities related to computers grows, there's no good reason to continue to erect a strawman about the language and set fire to it.

jblow 10y ago
You can't pass an array to a procedure without it becoming a pointer. But that is not even the issue ... the issue is that even if you know something is an array, any pointer of any type could be pointing anywhere into the interior of that array.
- ArkyBeagle 10y ago
  If you 1) Know the base address of the array. 2) Know the offset of the element(s) you're passing 2a) Know the declared length ( or other upper limit for the array ). then you need never refer to any element of an array that doesn't exist.
  - jblow 10y ago
    That's not the problem. The problem is any other live pointer could point into that array, for all the compiler knows. Unless the array was generated locally and never aliased, then if you ever call through some set of procedures that the compiler doesn't have complete visibility into, then it is possible that that code generates a pointer into that array and then uses it. The compiler has to be VERY conservative.

jblow 10y ago

You can't pass an array to a procedure without it becoming a pointer. But that is not even the issue ... the issue is that even if you know something is an array, any pointer of any type could be pointing anywhere into the interior of that array.

ArkyBeagle 10y ago
If you 1) Know the base address of the array. 2) Know the offset of the element(s) you're passing 2a) Know the declared length ( or other upper limit for the array ). then you need never refer to any element of an array that doesn't exist.
- jblow 10y ago
  That's not the problem. The problem is any other live pointer could point into that array, for all the compiler knows. Unless the array was generated locally and never aliased, then if you ever call through some set of procedures that the compiler doesn't have complete visibility into, then it is possible that that code generates a pointer into that array and then uses it. The compiler has to be VERY conservative.