pointers and strings

RedX

Would it be correct to say that C prevents you from writing self-modifying code by preventing you access to the addresses where code is stored, and that is the primary reason that not initializing pointers is dangerous? And why can't the language automatically set each pointer to NULL? Is this just a waste of the compiler's time?

airborne18

First, some compilers have options that force automatic initialization, but forget that. C does not guarantee the initial state of any variable. The fact that your compiler might do it for you, it is poor practice.

forget pointers.. lets stick to a simple example.

int a; // what is the value of a? who knows

int a = 0; // now you know what it is

now lets foget strings. just confuses people..

int *a = NULL; // it is pointer.. initialized to NULL.. try and do anyting in this state and you will get an easy to understand error.

int b[5]; // now we have an array of integers.. 5 of them.. what are their values?? anything
int b[5] = {1,2,3,4,5}; // now we have the same array, with initial values.. cleaner.
or

int b[] = { 1,2,3,4,5} // same as above.


so you can access b like this.

b[0] = 2;
b[1] = 3;
b[2] = 4;
b[3] = 5;
b[4] = 6;
b[5] = 7; // Oops this is wrong.. the size of b is 5 memory spots,, 0 - 4, not 1 -5 and not 0-5 some compiliers will catch this.


// what is the difference between an array and a pointer.. nothing.. in reality.. but alot in implementation. both are blocks of memory.

a = &b[0] // give a the start of our array b..

a[0] = 1;
a[1] = 2;
a[2] = 3;
a[3] = 4;
a[4] = 5;
a[5] = 6; // again.. big no-no. though the compiler will not catch it.. it has no idea how big a is.. b it knows, because it is declared space, a is not. it is just a pointer..

also notice I did not have to do *a to assign.. why? because a pointer and an array are the same thing, except for how the memory is allocated.
With a pointer, you assume all liability for where it points, and that the memory block is valid.

with an array, it is allocated by the compiler on the stack. ( you should avoid this ).

instead of this a[0] = 1 you can do this.

*a = 1;
and then keep incrementing the pointer, but array notation is easier.

or even
*(a+1)=2; // this is position a[1]..

I have not touched memory allocation because it will confuse the situation.. you have to understand the above examples...




The beauty of C is that you can do anything, and the pitfall of C is that you can do anything. It is the reason that you learned Pascal first, then C.

Hurkyl

Once upon a time, writing through a random pointer could corrupt the operating system. These days, your only fear is giving a hook for hackers.

However, errors with pointers are notoriously difficult to debug -- initializing everything is one approach to trying to ameliorate that problem.

Example 1: You might not notice an error when debugging and seeing that your program wrote through a pointer with value 0xb854cca0, but it's stands out if the value is 0x00000000!

Example 2: A particularly subtle bug is when you sometimes (or always!) fail to initialize a needed variable in your function. However, because of the way it's used, along with compiler, operating system, hardware behavior, that variable by chance picks up a correct or reasonable value. e.g. if a variable is supposed to be initialized to zero, you write a program specifically to try and debug it -- you'll never encounter the error if the operating system initializes stack to all 0's!


It could. Java takes that approach. C rejects it, I presume for the sake of efficiency -- a very short function function call might spend more time in irrelevant initialization than actually using useful work, and if it gets called a billion times....

A good compiler might be able to eliminate redundant initializations or delay initialization until it knows it to be useful. But there will be limitations on how well it performs, and offers extra chances for the compiler to produce buggy code. Also, recall that C was standardized back when compilers were fairly dumb, relatively speaking.


Some compilers or other environments offer "debug" modes that do a lot of things to help you debug, though. e.g. one version of malloc on some systems will fill memory with the byte pattern 0xdeadbeef. So when some of your variables start showing up with that hex value, you know something is wrong.