Into, but not out of, the void - Embedded.com

Into, but not out of, the void

The early dialect of C described by Kernighan and Ritchie (Kernighan, Brian W. and Ritchie, Dennis M., The C Programming Language . Prentice Hall, 1978.) (often called “Classic C”) didn't include the keyword void , and therefore had no type void * . Lacking void * , Classic C programs tended to use char * as the type for a “generic” data pointer–a pointer that can point to any data object. Unfortunately, this increased the need to use cast expressions.

For example, Classic C didn't include the now standard memory management functions malloc and free . On page 175 of their book, Kernighan and Ritchie implemented their own allocation function, alloc , which they defined as:

char *alloc(bytes)unsigned bytes;{    ...}   

This function definition is in the old, non-prototyped style of Classic C. In Standard C, the equivalent declaration would be:

char *alloc(unsigned bytes);   

This alloc function returns the address of the allocated storage as a pointer of type char * . However, they designed alloc to allocate storage for any type of object, not just char or array of char . When allocating storage for something other than a char (or array thereof), the program must convert the char * result into a pointer to the intended type of the allocated object–a conversion that requires a cast. Kernighan and Ritchie used casts to convert the result of calling alloc to something other than char * , in functions such as:

struct tnode *talloc(){   return ((struct tnode *)alloc(sizeof(struct tnode)));}   

The Classic C implementation of free posed a similar problem. Kernighan and Ritchie defined their version of free as:

free(ap)char *ap{    ...}   

Absent the keyword void , they omitted the return type to indicate that the function returns nothing. In truth, the return type defaulted to int . In Standard C, the equivalent declaration would be:

int free(char *ap);   

Calling free to deallocate anything other than a char or array of chars required a cast, as in:

int *ip;...free((char *)ip);   

Standard C eliminated the need for these casts by embracing void * as the generic data pointer type. For any object type T , a C program can convert a T * to or from a void * without using a cast.

For example, Standard C declares malloc and free as:

void *malloc(size_t size);void free(void *p);   

so that for any object type T :

T *p;...p = malloc(sizeof(T));...free(p);   

should compile in C without complaint. No casting needed.

An unfortunate consequence of the C's pointer conversion rules is that they permit accidental conversions between unrelated pointer types. For example:

double *pd;long *pl;void *pv;...pv = pd;            // compiles in C...pl = pv;            // compiles in C   

Although pl is declared to point to a long , it now points to a double . Accessing *pl would produce undefined behavior.

C++ reduces the chances of such mishaps by applying slightly more restrictive conversion rules: for any object type T , a C++ program can convert a T * to a void * , but not a void * to a T * . Here's the rationale.

Converting from T * to void * is generally safe because the program can do little harm with a void * object. For example, if pv has type void * , compilers reject attempts to access the object to which pv points. Expressions such as *pv , pv[i] , ++pv , and –pv simply don't compile.

Although converting a pointer such as pv from void * to T * (for any non-void T ) is itself safe, it throws the door wide open for future unsafe operations, such as accidentally converting an object into something that it really isn't.

Thus, for any (non-void ) object type T , C++ requires a cast when converting from void * to T * , as in:

pv = pd;            // compiles in C and C++...pl = pv;            // compiles in C, but not in C++pl = (long *)pv;    // compiles in C and C++   

Using a cast enables the code to compile, but doesn't eliminate the undefined behavior. In this case, the cast really is an indicator that the operation is unsafe.

Thanks to Steve Adamczyk of Edison Design Group (www.edg.com) for helping me identify parts of the standard relevant to this discussion.

Dan Saks is president of Saks & Associates, a C/C++ training and consulting company. For more information about Dan Saks, visit his website at www.dansaks.com. Dan also welcomes your feedback: e-mail him at . For more information about Dan .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.