Const and volatile
These are new in Standard
C, although the idea of
const has been borrowed from
C++. Let us get one thing straight: the concepts of
const and
volatile are
completely independent. A common misconception is to imagine that somehow
const is the opposite of
volatile and vice versa. They are unrelated and you should remember the fact.
Since
const declarations are the simpler, we'll look at them first, but only after we have seen where both of these type qualifiers may be used. The complete list of relevant keywords is
char long float volatile
short signed double void
int unsigned const
In that list,
const and
volatile are type qualifiers, the rest are
type specifiers. Various combinations of type specifiers are permitted:
char, signed char, unsigned char
int, signed int, unsigned int
short int, signed short int, unsigned short int
long int, signed long int, unsigned long int
float
double
long double
A few points should be noted. All declarations to do with an
int will be
signed anyway, so signed is redundant in that context. If
any other type specifier or qualifier is present, then the int part may be dropped, as that is the default.
The keywords
const and
volatile can be applied to any declaration, including those of structures, unions, enumerated types or
typedef names. Applying them to a declaration is called
qualifying the declaration—that's why const and volatile are called type qualifiers, rather than type specifiers. Here are a few representative examples:
volatile i;
volatile int j;
const long q;
const volatile unsigned long int rt_clk;
struct{
const long int li;
signed char sc;
}volatile vs;Don't be put off; some of them are deliberately complicated: what they mean will be explained later. Remember that they could also be further complicated by introducing storage class specifications as well! In fact, the truly spectacular
extern const volatile unsigned long int rt_clk;
is a strong possibility in some real-time operating system kernels.
Const
Let's look at what is meant when
const is used. It's really quite simple:
const means that something is not modifiable, so a data object that is declared with
const as a part of its type specification must not be assigned to in any way during the run of a program. It is very likely that the definition of the object will contain an initializer (otherwise, since you can't assign to it, how would it ever get a value?), but this is not always the case. For example, if you were accessing a hardware port at a fixed memory address and promised only to read from it, then it would be declared to be
const but not initialized.
Taking the address of a data object of a type which isn't
const and putting it into a pointer to the
const-qualified version of the same type is both safe and explicitly permitted; you will be able to use the pointer to inspect the object, but not modify it. Putting the address of a const type into a pointer to the unqualified type is much more dangerous and consequently prohibited (although you can get around this by using a cast). Here is an example:
#include
#include
main(){
int i;
const int ci = 123;
/* declare a pointer to a const.. */
const int *cpi;
/* ordinary pointer to a non-const */
int *ncpi;
cpi = &ci;
ncpi = &i;
/*
* this is allowed
*/
cpi = ncpi;
/*
* this needs a cast
* because it is usually a big mistake,
* see what it permits below.
*/
ncpi = (int *)cpi;
/*
* now to get undefined behaviour...
* modify a const through a pointer
*/
*ncpi = 0;
exit(EXIT_SUCCESS);
}
Example As the example shows, it is possible to take the address of a constant object, generate a pointer to a non-constant, then use the new pointer. This is an
error in your program and results in undefined behaviour.
The main intention of introducing const objects was to allow them to be put into read-only store, and to permit compilers to do extra consistency checking in a program. Unless you defeat the intent by doing naughty things with pointers, a compiler is able to check that
const objects are not modified explicitly by the user.
An interesting extra feature pops up now. What does this mean?
char c;
char *const cp = &c;
It's simple really;
cp is a pointer to a
char, which is exactly what it would be if the
const weren't there. The
const means that
cp is not to be modified, although whatever it points to can be—the pointer is constant, not the thing that it points to. The other way round is
const char *cp;
which means that now cp is an ordinary, modifiable pointer, but the thing that it points to must not be modified. So, depending on what you choose to do, both the pointer and the thing it points to may be modifiable or not; just choose the appropriate declaration.
Volatile
After const, we treat
volatile. The reason for having this type qualifier is mainly to do with the problems that are encountered in real-time or embedded systems programming using C. Imagine that you are writing code that controls a hardware device by placing appropriate values in hardware registers at known absolute addresses.
Let's imagine that the device has two registers, each 16 bits long, at ascending memory addresses; the first one is the control and status register (csr) and the second is a data port. The traditional way of accessing such a device is like this:
/* Standard C example but without const or volatile */
/*
* Declare the device registers
* Whether to use int or short
* is implementation dependent
*/
struct devregs{
unsigned short csr; /* control & status */
unsigned short data; /* data port */
};
/* bit patterns in the csr */
#define ERROR 0x1
#define READY 0x2
#define RESET 0x4
/* absolute address of the device */
#define DEVADDR ((struct devregs *)0xffff0004)
/* number of such devices in system */
#define NDEVS 4
/*
* Busy-wait function to read a byte from device n.
* check range of device number.
* Wait until READY or ERROR
* if no error, read byte, return it
* otherwise reset error, return 0xffff
*/
unsigned int read_dev(unsigned devno){
struct devregs *dvp = DEVADDR + devno;
if(devno >= NDEVS)
return(0xffff);
while((dvp->csr & (READY | ERROR)) == 0)
; /* NULL - wait till done */
if(dvp->csr & ERROR){
dvp->csr = RESET;
return(0xffff);
}
return((dvp->data) & 0xff);
}Example The technique of using a structure declaration to describe the device register layout and names is very common practice. Notice that there aren't actually any objects of that type defined, so the declaration simply indicates the structure without using up any store.
To access the device registers, an appropriately cast constant is used as if it were pointing to such a structure, but of course it points to memory addresses instead.
However, a major problem with previous C compilers would be in the while loop which tests the status register and waits for the
ERROR or
READY bit to come on. Any self-respecting optimizing compiler would notice that the loop tests the same memory address over and over again. It would almost certainly arrange to reference memory once only, and copy the value into a hardware register, thus speeding up the loop. This is, of course, exactly what we don't want; this is one of the few places where we must look at the place where the pointer points, every time around the loop.
Because of this problem, most C compilers have been unable to make that sort of optimization in the past. To remove the problem (and other similar ones to do with when to write to where a pointer points), the keyword
volatile was introduced. It tells the compiler that the object is subject to sudden change for reasons which cannot be predicted from a study of the program itself, and forces every reference to such an object to be a genuine reference.
Here is how you would rewrite the example, making use of
const and
volatile to get what you want.
/*
* Declare the device registers
* Whether to use int or short
* is implementation dependent
*/
struct devregs{
unsigned short volatile csr;
unsigned short const volatile data;
};
/* bit patterns in the csr */
#define ERROR 0x1
#define READY 0x2
#define RESET 0x4
/* absolute address of the device */
#define DEVADDR ((struct devregs *)0xffff0004)
/* number of such devices in system */
#define NDEVS 4
/*
* Busy-wait function to read a byte from device n.
* check range of device number.
* Wait until READY or ERROR
* if no error, read byte, return it
* otherwise reset error, return 0xffff
*/
unsigned int read_dev(unsigned devno){
struct devregs * const dvp = DEVADDR + devno;
if(devno >= NDEVS)
return(0xffff);
while((dvp->csr & (READY | ERROR)) == 0)
; /* NULL - wait till done */
if(dvp->csr & ERROR){
dvp->csr = RESET;
return(0xffff);
}
return((dvp->data) & 0xff);
}Example The rules about mixing
volatile and regular types resemble those for
const. A pointer to a
volatile object can be assigned the address of a regular object with safety, but it is dangerous (and needs a cast) to take the address of a
volatile object and put it into a pointer to a regular object. Using such a derived pointer results in undefined behaviour.
If an array, union or structure is declared with
const or
volatile attributes, then all of the members take on that attribute too. This makes sense when you think about it—how could a member of a
const structure be modifiable?
That means that an alternative rewrite of the last example would be possible. Instead of declaring the device registers to be
volatile in the structure, the pointer could have been declared to point to a
volatile structure instead, like this:
struct devregs{
unsigned short csr; /* control & status */
unsigned short data; /* data port */
};
volatile struct devregs *const dvp=DEVADDR+devno;Since
dvp points to a
volatile object, it not permitted to optimize references through the pointer. Our feeling is that, although this would work, it is bad style. The
volatile declaration belongs in the structure: it is the device registers which are
volatile and that is where the information should be kept; it reinforces the fact for a human reader.
So, for any object likely to be subject to modification either by hardware or asynchronous interrupt service routines, the volatile type qualifier is important.
Now, just when you thought that you understood all that, here comes the final twist. A declaration like this:
volatile struct devregs{
/* stuff */
}v_decl;declares the type
struct devregs and also a
volatile-qualified object of that type, called
v_decl. A later declaration like this
struct devregs nv_decl;
declares
nv_decl which is
not qualified with
volatile! The qualification is
not part of the type of
struct devregs but applies only to the declaration of
v_decl. Look at it this way round, which perhaps makes the situation more clear (the two declarations are the same in their effect):
struct devregs{
/* stuff */
}volatile v_decl;If you do want to get a shorthand way of attaching a qualifier to another type, you can use
typedef to do it:
struct x{
int a;
};
typedef const struct x csx;
csx const_sx;
struct x non_const_sx = {1};
const_sx = non_const_sx; /* error - attempt to modify a const */Indivisible Operations
Those of you who are familiar with techniques that involve hardware interrupts and other ‘real time’ aspects of programming will recognise the need for
volatile types. Related to this area is the need to ensure that accesses to data objects are ‘atomic’, or uninterruptable. To discuss this is any depth would take us beyond the scope of this book, but we can at least outline some of the issues.
Be careful not to assume that any operations written in C are uninterruptable. For example,
extern const volatile unsigned long realtimeclock;
could be a counter which is updated by a clock interrupt routine. It is essential to make it
volatile because of the asynchronous updates to it, and it is marked
const because it should not be changed by anything other than the interrupt routine. If the program accesses it like this:
unsigned long int time_of_day;
time_of_day = real_time_clock;
there may be a problem. What if, to copy one
long into another, it takes several machine instructions to copy the two words making up
real_time_clock and
time_of_day? It is possible that an interrupt will occur in the middle of the assignment and that in the worst case, when the low-order word of
real_time_clock is
0xffff and the high-order word is
0x0000, then the low-order word of
time_of_day will receive
0xffff. The interrupt arrives and increments the low-order word of
real_time_clock to
0x0 and then the high-order word to
0x1, then returns. The rest of the assignment then completes, with
time_of_day ending up containing
0x0001ffff and
real_time_clock containing the correct value,
0x00010000.
This whole class of problem is what is known as a critical region, and is well understood by those who regularly work in asynchronous environments. It should be understood that Standard C takes no special precautions to avoid these problems, and that the usual techniques should be employed.
The header
‘signal.h’ declares a type called
sig_atomic_t which is guaranteed to be modifiable safely in the presence of asynchronous events. This means only that it can be modified by assigning a value to it; incrementing or decrementing it, or anything else which produces a new value depending on its previous value, is not safe.
