when should the volatile modifier be used?
The volatile modifier is a directive to the compiler’s optimizer that operations involving this variable should not be optimized in certain ways. There are two special cases in which use of the volatile modifier is desirable. The first case involves memory-mapped hardware (a device such as a graphics adaptor that appears to the computer’s hardware as if it were part of the computer’s memory), and the second involves shared memory (memory used by two or more programs running simultaneously). Most computers have a set of registers that can be accessed faster than the computer’s main memory. A good compiler will perform a kind of optimization called redundant load and store removal. The compiler looks for places in the code where it can either remove an instruction to load data from memory because the value is already in a register, or remove an instruction to store data to memory because the value can stay in a register until it is changed again anyway. If a variable is a pointer to something other than normal memory, such as memory-mapped ports on a peripheral, redundant load and store optimizations might be detrimental. For instance, here’s a piece of code that might be used to time some operation: time_t time_addition(volatile const struct timer *t, int a) { int n; int x; time_t then; x = 0; then = t->value; for (n = 0; n < 1000; n++) { x = x + a; } return t->value - then; }
In this code, the variable t-> value is actually a hardware counter that is being incremented as time passes. The function adds the value of a to x 1000 times, and it returns the amount the timer was incremented by while the 1000 additions were being performed. Without the volatile modifier, a clever optimizer might assume that the value of t does not change during the execution of the function, because there is no statement that explicitly changes it. In that case, there’s no need to read it from memory a second time and subtract it, because the answer will always be 0. The compiler might therefore optimize the function by making it always return 0. If a variable points to data in shared memory, you also don’t want the compiler to perform redundant load and store optimizations. Shared memory is normally used to enable two programs to communicate with each other
malloc(0) does not return a non-NULL under every implementation. An implementation is free to behave in a manner it finds suitable, if the allocation size requested is zero. The implmentation may choose any of the following actions:
* A null pointer is returned.
* The behavior is same as if a space of non-zero size was requested. In this case, the usage of return value yields to undefined-behavior.
Notice, however, that if the implementation returns a non-NULL value for a request of a zero-length space, a pointer to object of ZERO length is returned! Think, how an object of zero size should be represented?
For implementations that return non-NULL values, a typical usage is as follows:
void func ( void ) { int *p; /* p is a one-dimensional array, whose size will vary during the the lifetime of the program */ size_t c;
p = malloc(0); /* initial allocation */ if (!p) { perror (”FAILURE” ); return; }
/* … */
while (1) { c = (size_t) … ; /* Calculate allocation size */ p = realloc ( p, c * sizeof *p );
/* use p, or break from the loop */ /* … */ } return; }
Notice that this program is not portable, since an implementation is free to return NULL for a malloc(0) request, as the C Standard does not support zero-sized objects.
C has three types of storage: automatic, static and allocated.
Variable having block scope and without static specifier have automatic storage duration.
Variables with block scope, and with static specifier have static scope. Global variables (i.e, file scope) with or without the the static specifier also have static scope.
Memory obtained from calls to malloc(), alloc() or realloc() belongs to allocated storage class.
A Great Tutorials Portal
Aquarian Infotech System
Copyright © 2008 interviewmaterial.com. All rights reserved.