Thread: "Pointers" <-- crappy name

Which takes us back to:

Originally Posted by argv

so many books and 'tutorials' and whatever do a horrible job of explaining what a pointer is.

And I completely agree. Because I now understand what a pointer is, the Koenig and Moo statement makes sense (pointlessly). If I did not know, I doubt very much that it were serve to clarify the matter. At all.

One day in the distant future maybe I will write a book for beginner's on C. I can totally remember going through material and thinking I'd like to, because much of the material is so bad. I honestly believe the standard of technical writing on CS and programming is a often a low one. This may be similar to other academic fields which suffer from a lack of original sources for material and must depend on a slightly inbred circus of "my teacher wrote the textbook I am required to pay for".

In turn, the style of this low standard is taken up by people who prepare tutorials, etc, and gradually disseminates itself into acceptability. Once you know the language, it obviously easy to defend a piece of work by saying, "Well, the code is not wrong" or even "the code is good" and opinions on the kind of discourse you site above will be "subjective". What they are saying may be true, but it is almost semantic obfuscation masquerading as an "explanation".

Originally Posted by Brafil

But the required knowledge is almost never written anywhere.

Yes! This what I meant by

Originally Posted by MK27

it is not because of the name; it is because of the strong elliptical tradition in programming "instructional" discourse, which is virtually the de facto standard. You could call it anything, it will not improve the quality of the material to which you refer.

Maybe the idea is to *hack* your way into understanding.

Originally Posted by argv

The best thing I've learned is that if you want to learn something, learn it from someone who knows how to teach things. I.e. if a book is used in a college class, it's probably a good book to have on the shelf.

Generally true, although we have seen a few examples here where there is a university lecturer with bigger ego than educational skill that writes a book and then uses that for the education in the school. Not always such a good thing.

--
Mats

Some bogus statements:

No, string is an array of allocates bytes in which the string is stored.

This is a recursive definition. "A string is something in which the string is stored". I like the following definition: a string is a null-terminated array of chars. This way, we avoid talking about memory, bytes, allocation and so on.

A pointer is a value stored in memory.

Certainly not. Consider the following code:

Code:

int x = 17;

Now 17 is a value stored in memory. Is it a pointer? No.



Here's my definition of a pointer. But let's first define variables: a variable is a 4-tuple consisting of name, size, address and value.

Now it's easy to define pointers: a pointer is a variable whose value is an address.


Pointers are not addresses, and addresses are not pointers: it doesn't make sense to ask for the address of an address, the size of an address or the name of an address. For pointers, these questions are easily answered. But for the sake of simplicity, we may sloppily call pointers "addresses" and vice versa if the context doesn't require further distinction.

Greets,
Philip

A pointer can be a value stored in memory (or in swap space or in a register).

A pointer is a variable whose value is an address in memory. This graph shows you the contents of "pointer".

Code:

     +----------------+
     |   0x3f93f84e   |       ------------------------->    Memory location at 0x3f93f84e
     +----------------+

        int *pointer;

Then programmers say that pointer "points to" the thing that is at memory address 0x3f93f84e.

If you say *pointer, you mean you wanna access whatever is at memory location at 0x3f93f84e. Since you meant pointer to be a pointer to _int_ (int *pointer is a * (pointer) to int), the computer fetches an _int_eger from memory location 0x3f93f84e.

Code:

     +----------------+
     |   0x3f93f84e   |       ------------------------->   Segmentation Fault
     +----------------+

   printf("%d\n", *pointer);

What happened? That's strange! But the solution is easy. The pointer is uninitialized. That means, it's value is undefined (probably not what you want). Since the space where pointer is stored (pointers are also stored in memory) has probably been used before, it will contain some crap left from other programs or your own program. This crap is 0x3f93f84e. The computer doesn't know that, it makes just what you want - in this case, it fetches an integer from somewhere in you memory.

BUT - That's a security risk. What if 0x3f93f84e points to operating system data or *where your passwords are stored in*? Then any hacker can get into your computer by accessing anything he wants. He makes the pointer "point to" somewhere he wants, for example where your login name and password are stored. Then he accesses that location. Voila, he has you name and password, if they are not encrypted (don't worry about this part).

Or say, you want to modify *pointer. You could write zeros there where your operating system's heart is beating. That would immediately crash your computer. Either you didn't want this to happen, or a hacker wanted to kill your session. Too late. You've lost your 1000 line program cuz you didn't save.

To prevent this from happening, the operating system doesn't allow you to look at position 0x3f93f84e in memory. It neither allows you to write there. For your own security. That's, PAY ATTENTION where you pointers point to.

Code:

     +----------------+                                   +----------------+
     |   0xac398ef4   |       ------------------------->  |   0x00000000   |
     +----------------+                                   +----------------+
 
        pointer = &i;                                         int i = 0;

Now you say, "make pointer point to i", or "gimme the address of i and save it in pointer". The '&' operator takes the address of something, for example i. It returns 0xac398ef4 in this case, which is the memory location where i is saved in. So the value of pointer is the address of i.

(Of course, we have assigned i to zero, that means in fact we have written all zeros into the location where i resides)

Now, let's take a look at i. We could simply write "printf("%d\n", i)". But that's boring! We wanna learn something. Ok, let's try to use pointer. Remembered the part with the Segmentation Fault? Try again!

Code:

     +----------------+                                   +----------------+
     |   0xac398ef4   |       ------------------------->  |   0x00000000   |
     +----------------+                                   +----------------+
 
  printf("%d\n", *pointer);                                        i

Compile... Run... YESSS! No strange errors, just plain zero. i was zero, remember? Now we get the same zero! What happened? We wanted to fetch an integer from memory location 0xac398ef4. Now we know that we can read from there, cuz it's *our* memory and nobody else can read from there except we can. We own i, so we own 0xac398ef4 where i is stored. Congrats, for you own some memory now!

But what if we want to put a 5 into i? "i = 5;", right? BOORING! We can do it like that:

Code:

     +----------------+                                   +----------------+
     |   0xac398ef4   |       ------------------------->  |   0x00000005   |
     +----------------+                                   +----------------+

       *pointer = 5;                                               i

Now we say "write a 5 wherever pointer points to!". Since pointer points to i, we write 5 into i. Now, test i:

Code:

     +----------------+                                   +----------------+
     |   0xac398ef4   |       ------------------------->  |   0x00000005   |
     +----------------+                                   +----------------+

  printf("%d\n", *pointer);                                        i

Compile... Run. What do we see? We printed out *pointer first remember?, that gave us a zero. Now, we write a 5 into the location where i lives. Now, we print out i... The output is... 5! Wow! Cool, huh? If we print *pointer again, we'll get another 5. If you assign i to 293, *pointer will give you 293. It's just always the same number.

That was the basics. Anyone who doesn't understand can tell me. Don't be ashamed, I'm sure probably _nobody_ here knew it since s/he was a baby. But once you get it, you know very much. Pointers are one of the REAL powers of C.

Originally Posted by Snafuist

I like the following definition: a string is a null-terminated array of chars. This way, we avoid talking about memory, bytes, allocation and so on.

The official definition is: "a string is a contiguous sequence of characters terminated by and including the first null character." This is more accurate since a string might only occupy part of an array.

These are definitions for C-style strings. There is no requirement on std::string to be null-terminated, for example, yet it still is a string.

More generally, a string is a contiguous sequence of characters. Not necessarily contiguous in memory (sgi's rope isn't, nor are typical strings in functional languages), just in concept - a string has no holes.

Originally Posted by CornedBee

These are definitions for C-style strings.

Yes, hence "official" in this context means "as defined by the C standard".

Originally Posted by Brafil

BUT - That's a security risk. What if 0x3f93f84e points to operating system data or *where your passwords are stored in*? Then any hacker can get into your computer by accessing anything he wants. He makes the pointer "point to" somewhere he wants, for example where your login name and password are stored. Then he accesses that location. Voila, he has you name and password, if they are not encrypted (don't worry about this part).

My instructor once blew the bounds of an array and wrote to the part of the computer that tells the computer to write to random parts of the hard drive

Originally Posted by ಠ_ಠ

My instructor once blew the bounds of an array and wrote to the part of the computer that tells the computer to write to random parts of the hard drive

On any modern operating system, that is impossible.
But it is possible to overwrite other sensitive data by writing out of bounds (it might even have corrupted a buffer that holds contents to write to the disk in an open file).