Pointers - C Interview Questions III

Q. Can you subtract pointers from each other? Why would you?

If you have two pointers into the same array, you can subtract them. The answer is the number of elements between the two elements.

Consider the street address analogy presented in the introduction of this chapter. Say that I live at 118 Fifth Avenue and that my neighbor lives at 124 Fifth Avenue. The "size of a house" is two (on my side of the street, sequential even numbers are used), so my neighbor is (124-118)/2 (or 3) houses up from me. (There are two houses between us, 120 and 122; my neighbor is the third.) You might do this subtraction if you're going back and forth between indices and pointers.

You might also do it if you're doing a binary search. If p points to an element that's before what you're looking for, and q points to an element that's after it, then (q-p)/2+p points to an element between p and q. If that element is before what you want, look between it and q. If it's after what you want, look between p and it.

(If it's what you're looking for, stop looking.)

You can't subtract arbitrary pointers and get meaningful answers. Someone might live at 110 Main Street, but I can't subtract 110 Main from 118 Fifth (and divide by 2) and say that he or she is four houses away!

If each block starts a new hundred, I can't even subtract 120 Fifth Avenue from 204 Fifth Avenue. They're on the same street, but in different blocks of houses (different arrays).

C won't stop you from subtracting pointers inappropriately. It won't cut you any slack, though, if you use the meaningless answer in a way that might get you into trouble.

When you subtract pointers, you get a value of some integer type. The ANSI C standard defines a typedef,ptrdiff_t, for this type. (It's in <stddef.h>.) Different compilers might use different types (int or long or whatever), but they all define ptrdiff_t appropriately.

Below is a simple program that demonstrates this point. The program has an array of structures, each 16 bytes long. The difference between array[0] and array[8] is 8 when you subtract struct stuff pointers, but 128 (hex 0x80) when you cast the pointers to raw addresses and then subtract.

If you subtract 8 from a pointer to array[8], you don't get something 8 bytes earlier; you get something 8 elements earlier.

#include <stdio.h>

#include <stddef.h>

struct stuff {

        char    name[16];

        /* other stuff could go here, too */

};

struct stuff array[] = {

        { "The" },

        { "quick" },

        { "brown" },

        { "fox" },

        { "jumped" },

        { "over" },

        { "the" },

        { "lazy" },

        { "dog." },

        { "" }

};

int main()

{

        struct stuff    *p0 = & array[0];

        struct stuff    *p8 = & array[8];

        ptrdiff_t       diff = p8 - p0;

        ptrdiff_t       addr_diff = (char*) p8 - (char*) p0;

        /* cast the struct stuff pointers to void* */

        printf("& array[0] = p0 = %P\n", (void*) p0);

        printf("& array[8] = p8 = %P\n", (void*) p8);

        /* cast the ptrdiff_t's to long's

        (which we know printf() can handle) */

        printf("The difference of pointers is %ld\n",

          (long) diff);

        printf("The difference of addresses is %ld\n",

          (long) addr_diff);

        printf("p8 - 8 = %P\n", (void*) (p8 - 8));

        printf("p0 + 8 = %P (same as p8)\n", (void*) (p0 + 8));

        return 0;  

}

Q. Is NULL always defined as 0(zero)?

NULL is defined as either 0 or (void*)0. These values are almost identical; either a literal zero or a void pointer is converted automatically to any kind of pointer, as necessary, whenever a pointer is needed (although the compiler can't always tell when a pointer is needed).

Q. Is NULL always equal to 0(zero)?

The answer depends on what you mean by "equal to." If you mean "compares equal to," such as

if ( /* ... */ )

{

     p = NULL;

}

else

{

     p = /* something else */;

}

/* ... */

if ( p == 0 )

then yes, NULL is always equal to 0. That's the whole point of the definition of a null pointer.

If you mean "is stored the same way as an integer zero," the answer is no, not necessarily. That's the most common way to store a null pointer. On some machines, a different representation is used.

The only way you're likely to tell that a null pointer isn't stored the same way as zero is by displaying a pointer in a debugger, or printing it. (If you cast a null pointer to an integer type, that might also show a nonzero value.)