Question

I am reading article from Stanford CS library http://cslibrary.stanford.edu/102/

Bad Pointer Example
Code with the most common sort of pointer bug will look like the above correct code, but without the middle step where the pointers are assigned pointees. The bad code will compile fine, but at run-time, each dereference with a bad pointer will corrupt memory in some way. The program will crash sooner or later. It is up to the programmer to ensure that each pointer is assigned a pointee before it is used. The following example shows a simple example of the bad code and a drawing of how memory is likely to react…

void BadPointer() {
   int* p;     // allocate the pointer, but not the pointee
   *p = 42;    // this dereference is a serious runtime error
}

// What happens at runtime when the bad pointer is dereferenced…

But I remember that char* should be defined like this

char *const name_ptr = "Test";

In this way, if everyone think about if this char* is a bad define?

Answer 1

The line

char *const name_ptr = "Test";

is fine; you’re initializing the pointer with the address of the string literal "Test", which is an array of char stored in such a way that the memory for it is allocated at program startup and held until the program terminates.

A quick digression on the const qualifier:

In C, declaration of the form

const T foo = expr;

or

T const foo = expr;

means that foo may not be written to; it’s assigned the value of expr when it’s created, and that value may not be changed for the rest of foo‘s lifetime¹⁾. With pointer variables, it gets a little more complicated:

const T *p = expr;
T const *p = expr;

both declare p as a non-const pointer to const data; IOW, you can change the value of p (p can point to different objects), but not the value of *p (you cannot change the value of what p points to).

T * const p = expr;

declares p as a const pointer to non-const data; you can change the value of what p points to (*p = ...), but you cannot change p to point to a different object.

const T * const p = expr;
T const * const p = expr;

both declare p as a const pointer to const data; you cannot change either the value of p or what p points to.

In C, string literals such as "Test" are stored as arrays of char, but attempting to modify the contents of a string literal is undefined behavior (depending on the platform, you may get an access violation). For safety’s sake, it’s usually a good idea to declare pointers to string literals as const char * or char const *, rather than char * const as in the example above.

As far as

void BadPointer() {
   int* p;     // allocate the pointer, but not the pointee
   *p = 42;    // this dereference is a serious runtime error
}

is concerned, p is an auto variable, which is not initialized to any particular value; it will contain a random bit string that may or may not correspond to a writable address. Because of this, the behavior of the statement *p = 42; is undefined – you may get an access violation, you may wind up overwriting something important and leave the program in a bad state, or it may appear to “work” with no issues (writing to some random memory area that is accessible and not important).

In general, it’s impossible to tell whether a given pointer value is valid or invalid from the pointer value alone²⁾. The one exception is the special pointer value NULL, which is a well-defined “nowhere” that’s guaranteed to compare unequal to any valid pointer value. Pointer variables declared at file scope (outside of any function) or with the static qualifier are implicitly initialized to NULL. Non-static, block-scope pointer variables should always be explicitly initialized with either NULL or a valid address. This way you can easily check to see if the pointer has been assigned a valid value:

int *p = NULL;
...
if (p != NULL) // or simply if (p)
{
  *p = 42;
}
else
{
  // p was not assigned a valid memory location
}

---

^{1) Note that, in C, foo is not a compile-time constant; it’s a regular run-time variable, you just cannot write to it. You cannot use it in a context that requires a compile-time constant.}

2) If you’re intimately familiar with your platform’s memory model you can make some educated guesses, but even then it’s not guaranteed.