The volatile modiIier 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 oI the
volatile modiIier is desirable. The Iirst case involves memory-mapped hardware (a device such
as a graphics adaptor that appears to the computer`s hardware as iI it were part oI the computer`s
memory), and the second involves shared memory (memory used by two or more programs
running simultaneously).
Most computers have a set oI registers that can be accessed Iaster than the computer`s main
memory. A good compiler will perIorm a kind oI optimization called redundant load and store
removal. The compiler looks Ior places in the code where it can either remove an instruction to
load data Irom 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.
II 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 oI code that might be used to time some operation:
timet timeaddition(volatile const struct timer *t, int a)

int n;
int x;
timet then;
x 0;
then t-~value;
Ior (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 Iunction adds the value oI a to x 1000 times, and it returns the amount the timer
was incremented by while the 1000 additions were being perIormed. Without the volatile
modiIier, a clever optimizer might assume that the value oI t does not change during the
execution oI the Iunction, because there is no statement that explicitly changes it. In that case,
there`s no need to read it Irom memory a second time and subtract it, because the answer will
always be 0.
The compiler might thereIore optimize the Iunction by making it always return 0.
II a variable points to data in shared memory, you also don`t want the compiler to perIorm
redundant load and store optimizations. Shared memory is normally used to enable two programs
to communicate with each other by having one program store data in the shared portion oI
memory and the other program read the same portion oI memory. II the compiler optimizes away
a load or store oI shared memory, communication between the two programs will be aIIected.
malloc(0) does not return a non-NULL under every implementation.
An implementation is Iree to behave in a manner it Iinds
suitable, iI the allocation size requested is zero. The
implmentation may choose any oI the Iollowing actions:

* A null pointer is returned.

* The behavior is same as iI a space oI non-zero size
was requested. In this case, the usage oI return
value yields to undeIined-behavior.

Notice, however, that iI the implementation returns a non-NULL
value Ior a request oI a zero-length space, a pointer to object
oI ZERO length is returned! Think, how an object oI zero size
should be represented?

For implementations that return non-NULL values, a typical usage
is as Iollows:
void
Iunc ( void )

int *p; /* p is a one-dimensional array,
whose size will vary during the
the liIetime oI the program */
sizet c;

p malloc(0); /* initial allocation */
iI (!p)

perror (FAILURE );
return;
}

/* . */

while (1)

c (sizet) . ; /* Calculate allocation size */
p realloc ( p, c * sizeoI *p );

/* use p, or break Irom the loop */
/* . */
}
return;
}
Notice that this program is not portable, since an implementation
is Iree to return NULL Ior a malloc(0) request, as the C Standard
does not support zero-sized objects.
CreaLe Lwo polnLers and seL boLh Lo Lhe sLarL of Lhe llsL updaLe each as follows
whlle (polnLer1)
polnLer1 polnLer1nexL
polnLer2 polnLer2nexL
lf (polnLer2) polnLer2polnLer2nexL
lf (polnLer1 polnLer2)
prlnL (clrcular)



lf a llsL ls clrcular aL some polnL polnLer2 wlll wrap around and be elLher aL Lhe lLem [usL before
polnLer1 or Lhe lLem before LhaL LlLher way lLs elLher 1 or 2 [umps unLll Lhey meeL
Yes. The const modiIier means that this code cannot change the value oI the variable, but that
does not mean that the value cannot be changed by means outside this code. For instance, in the
example in FAQ 8, the timer structure was accessed through a volatile const pointer.
The Iunction itselI did not change the value oI the timer, so it was declared const. However, the
value was changed by hardware on the computer, so it was declared volatile. II a variable is both
const and volatile, the two modiIiers can appear in either order.
The strcpy() Iunction is designed to work exclusively with strings. It copies each byte oI the
source string to the destination string and stops when the terminating null character () has been
moved.
On the other hand, the memcpy() Iunction is designed to work with any type oI data. Because not
all data ends with a null character, you must provide the memcpy() Iunction with the number oI
bytes you want to copy Irom the source to the destination.
1ext Segment 1he text segment conta|ns the actua| code to be executed Its usua||y sharab|e so
mu|t|p|e |nstances of a program can share the text segment to |ower memory requ|rements 1h|s
segment |s usua||y marked readon|y so a program cant mod|fy |ts own |nstruct|ons
? In|t|a||zed Data Segment 1h|s segment conta|ns g|oba| var|ab|es wh|ch are |n|t|a||zed by the
programmer
? Un|n|t|a||zed Data Segment A|so named bss (b|ock started by symbo|) wh|ch was an operator used
by an o|d assemb|er 1h|s segment conta|ns un|n|t|a||zed g|oba| var|ab|es A|| var|ab|es |n th|s segment
are |n|t|a||zed to 0 or NULL po|nters before the program beg|ns to execute
? 1he stack 1he stack |s a co||ect|on of stack frames wh|ch w||| be descr|bed |n the next sect|on When
a new frame needs to be added (as a resu|t of a new|y ca||ed funct|on) the stack grows downward
? 1he heap Most dynam|c memory whether requested v|a Cs ma||oc() and fr|ends or C++s new |s
do|ed out to the program from the heap 1he C ||brary a|so gets dynam|c memory for |ts own persona|
workspace from the heap as we|| As more memory |s requested on the f|y the heap grows upward