Thread: A pointer problem from a high school programming contest

Originally Posted by robatino

Here's a long and detailed thread on the subject:

http://groups.google.com/group/comp....18f6cccd56427d

Here's the relevant passage from that discussion:

The Rationale says the Committee considered defining
the effects at both ends (bilateral dispensations?), but
rejected it for efficiency reasons. Consider an array of
large elements -- structs of 32KB size, say. A system
that actually performed hardware checking of pointer values
could accommodate the one-past-the-end rule by allocating
just one extra byte after the end of the array, a byte that
the special pointer value could point at without setting off
the hardware's alarms. But one-before-the-beginning would
require an extra 32KB, just to hold data that could never
be used ...

I can understand the benefit of an architecture with fine-grained access control to memory. Yes, I absolutely can. But this is still ridiculous. What harm is there in POSSESSING a pointer which points out of bounds? If the architecture really is capable of fine-grained access control, then attempting to use this pointer will result in a fault ANYWAY. This is a completely arbitrary restriction that gives no real benefit whatsoever, while disallowing lots of completely reasonable code.

And get this: the standard specifically ALLOWS an uninitialized pointer. So somehow, you're going to have to tell the bounds-checking hardware "Hey, ignore this one particular pointer -- it's okay according to the C standard." Which of course forces language-specific concerns into the hardware, which is completely idiotic.

Originally Posted by Salem

What if said decrement resulted in address underflow, and an immediate trap without even trying to dereference it? The "it hasn't happened to me yet" defence isn't good enough.

I know of no architecture that would do that. So I admit that the code I write is actually a more restrictive version of C/C++ than the standard would indicate -- the code wouldn't work on such an architecture. But I really don't care. It's no different than writing programs that call getch(). Obviously, such programs are restricted to platforms where getch() is available. Whereas my code is restricted to platforms that don't fault when an invalid pointer value is loaded into a variable.

As I've stated in the past, portability is a spectrum. I understand that some of the code I write is not strictly standard C. But the reality is, it works everywhere. And I'm not talking "I tested it on Windows and Linux." A platform where it didn't work is a platform I would avoid. A system where simply loading an invalid pointer value into a register causes a fault is just plain dumb design.

It would be just as dumb to assume that some floating point operation using an uninitialised float would be just as harmless.

If you look at the newsgroup thread that spawned this discussion, there are others who agree with me. This particular facet of the standard is just plain stupid and largely irrelevant. Don't assume that because I choose to ignore this particular thing that I have no clue what portability means.

Originally Posted by robatino

I understand the need to sometimes compromise portability for functionality or efficiency. But can you give an example of a situation where allowing invalid pointer assignments is necessary for this? Loops can normally be trivially modified to avoid them with no loss of efficiency.

Here is the basic idiom:

Code:

char *start, *end;
start = array - 1; /* Oh no, the HORROR! */
end = array + length;
while(++start < end)
{
    /* Do something */
}

This is called "backward biasing," at least where I come from. Why do it this way? Because the value of "start" is the same, both inside the condition and inside the loop. Why does it matter? Reduction of confusion. Try writing a few hundred thousand lines of code and it will become clear. When this same pattern occurs hundreds or thousands (literally) of times in a code base, you aren't going to go through and change everything because of some "hypothetical" architecture where it could be problematic.

There is some funny guy on this board who likes to claim that "walking a pointer is more efficient than indexing an array." This did, in fact, used to be true. And so you see the above pattern in legacy code. All... over... the... place.

It's not like I'm referencing an undefined pointer. It's a syntactic convenience for crap's sake. I'm not giving it up because the standard says so.

Originally Posted by quzah

Code:

for( start = array,  end = array + length; start < end; start++ )

To each his own I suppose.


Quzah.

I agree. But I didn't write every line of code I'm responsible for. The fact is, this pattern is everywhere. New code I write usually just uses a for-loop over the index. But I sure as heck am not wasting two years "fixing" all the instances of this.

Originally Posted by robatino

I've never seen backward biasing - to me it looks far more confusing than quzah's version, which is basically how I've always seen forward loops done, and which doesn't generate invalid pointers.

It wasn't invented for clarity's sake I don't claim to have invented it, but I deal with code that uses it on a daily basis. I am not keen on fixing what isn't broke. To me it reads naturally, but as Quzah said, to each his own.

Also, consider that a lot of legacy C code was "hand translated" from other languages during the 80's and early 90's. So a lot of this stuff is a result of directly translating idioms from one language to another, which ends up looking funny. But this particular pattern isn't rare by any means.

Well I am quite new to the entire pointer C++ thing, so this seemed like good practice, can someone tell me if I am following through the program right?

Code:

void g (int i) { //Passes a copy of the inputted number?
   int*p; //Creates a pointer
   p=&i; //p Points to the address of i (which is a copy of the original number?);
   *p--; //Points to a non-existing address;
}

void h (int*p) { //Takes a reference to the inputted varible
   *p--; //*Doesnt* deincrement variable since -- is resolved before *
}

void i (int*p) { //Takes a reference to the inputted varible
   int i; //Creates a local varible i
   i=*p; //Assigns i the value of the inputted varible (why was it assigned to p in the first place?)
   i--; //decrements the local copy
}

int main() {
   int index=100;
   for(;index>0;index--) {  //Standard for loop.
      printf("*"); 
      f(index);
      g(index);
      h(&index);
      i(&index); 
   }
   //Prints * 100 times since none of the functions do anything
//Talk about a dumb program
}