Volatile

[Rajesh]

Dear All,


Where to use volatile variable?

Thanks
Rajesh

 

[Sriram Rajagopalan]

You can use the volatile in cases where the variable is pointing to a
location beyond the control of the program that declares the variable.

Hence the you indicate the compiler not to perform code optimizations on
that variable.And also the change in the value of the variable is not under
your programs control.

Example:
char far* ptr = (char far*)<farmemorylocation>
for(int k=0;k<10;k++)
int i=*ptr;

Here the code optimizer might do the following:
int i=*ptr;

Since the same location is read again and again....

But this might not serve your cause.Since the location "ptr" might be
changed by some other process;the above optimization does not make any
sense.

To avoid the compiler doing this you must indicate that the
location is volatile.

Regards,
Sriram Rajagopalan.

 

[Thomas Stegen]

Dear All,


Where to use volatile variable?

For example when the variable needs to be read from memory
every time it is used. Normally the compiler will try to
make it so that variables are stored in registers.

This might be because the variables can change without the
program knowing because of they monitor some hardware.

 

[Kingbarry2000]

Dear All,


Where to use volatile variable?

Thanks
Rajesh

Volatile is used in hardware drivers and ports.
When incoming data is put into memory, you set that memory word / buffer to
volatile to indicate that to the compiler.

 

[Dan Pop]

Where to use volatile variable?

Anywhere the value of an object may change behind compiler's back.
My favourite example:

#include <stdio.h>
#include <signal.h>

volatile sig_atomic_t gotsig = 0;

void handler(int signo)
{
gotsig = signo;
}

int main()
{
signal(SIGINT, handler);
puts("Press the interrupt key to exit.");
while (gotsig == 0) ;
printf ("The program received signal %d.\n", (int)gotsig);
return 0;
}

Dan

 

[Keith Thompson]

In <[email protected]>


Anywhere the value of an object may change behind compiler's back.
My favourite example:

#include <stdio.h>
#include <signal.h>

volatile sig_atomic_t gotsig = 0;

void handler(int signo)
{
gotsig = signo;
}

int main()
{
signal(SIGINT, handler);
puts("Press the interrupt key to exit.");
while (gotsig == 0) ;
printf ("The program received signal %d.\n", (int)gotsig);
return 0;
}

I don't see a guarantee in the standard that an object of type
sig_atomic_t can hold the value SIGINT (though I don't know of an
implementation where it can't).

 

[Dan Pop]

I don't see a guarantee in the standard that an object of type
sig_atomic_t can hold the value SIGINT (though I don't know of an
implementation where it can't).

If it cannot, the result will be implementation-defined. The program's
overall behaviour is not affected. In C89, at least.

Dan

 

[Keith Thompson]

If it cannot, the result will be implementation-defined. The program's
overall behaviour is not affected. In C89, at least.

In C89, if the value of SIGINT doesn't fit in a sig_atomic_t, the
program's output will be incorrect; it might print, for example,

The program received signal 42.

even though the actual value of SIGINT might be, for example, 298. It
doesn't affect the program's flow of control (if that's what you mean
by "overall behavior"), but it certainly affects its behavior.

In C99 the conversion of the value of SIGINT to sig_atomic_t could
even raise an implementation-defined signal under certain
circumstances.

 

[Dan Pop]

In C89, if the value of SIGINT doesn't fit in a sig_atomic_t, the
program's output will be incorrect; it might print, for example,

The program received signal 42.

even though the actual value of SIGINT might be, for example, 298. It
doesn't affect the program's flow of control (if that's what you mean
by "overall behavior"), but it certainly affects its behavior.

Who cares? The program still behaves as expected, and the probability
of this happening is zilch. You'd have a point if it were a real
life program (and not a demo) and if the wrong value would cause
unexpected/unintended behaviour.

In C99 the conversion of the value of SIGINT to sig_atomic_t could
even raise an implementation-defined signal under certain
circumstances.

I'm willing to bet no conforming C99 implementation will take advantage
of this piece of brain damage in the C99 standard, that breaks *correct*
C89 code, for no redeeming advantages.

Dan

 

[Keith Thompson]

Who cares? The program still behaves as expected, and the probability
of this happening is zilch. You'd have a point if it were a real
life program (and not a demo) and if the wrong value would cause
unexpected/unintended behaviour.

I care; I'm surprised you don't. Producing incorrect output hardly
qualifies as expected behavior.

The point is simply that sig_atomic_t is not a suitable type for
storing signal numbers.