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*)<farmemory location>
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.
"Rajesh" <ra****@trident infosol.com> wrote in message
news:b2******** *************** ***@posting.goo gle.com...

Dear All,
Where to use volatile variable?

Thanks
Rajesh

[Thomas Stegen]

Rajesh wrote:

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.

--
Thomas.

[Kingbarry2000]

"Rajesh" <ra****@trident infosol.com> wrote in message
news:b2******** *************** ***@posting.goo gle.com...

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.

--
hash:a
-----BEGIN PGP SIGNATURE-----
a
-----END PGP SIGNATURE-----

[Dan Pop]

In <b2************ **************@ posting.google. com> ra****@tridenti nfosol.com (Rajesh) writes:

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:

In <b2************ **************@ posting.google. com>
ra****@tridenti nfosol.com (Rajesh) writes:

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;
}

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).

--
Keith Thompson (The_Other_Keit h) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Dan Pop]

In <lz************ @cts.com> Keith Thompson <ks*@cts.com> writes:

Da*****@cern.c h (Dan Pop) writes:

In <b2************ **************@ posting.google. com>
ra****@tridenti nfosol.com (Rajesh) writes:

>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;
}

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
implementati on 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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:

In <lz************ @cts.com> Keith Thompson <ks*@cts.com> writes:

Da*****@cern.c h (Dan Pop) writes:

In <b2************ **************@ posting.google. com>
ra****@tridenti nfosol.com (Rajesh) writes:

>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;
}

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
implementati on 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.

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.

--
Keith Thompson (The_Other_Keit h) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Dan Pop]

In <lz************ @cts.com> Keith Thompson <ks*@cts.com> writes:

Da*****@cern.c h (Dan Pop) writes:

In <lz************ @cts.com> Keith Thompson <ks*@cts.com> writes:

>Da*****@cern.c h (Dan Pop) writes:
>> In <b2************ **************@ posting.google. com>
>> ra****@tridenti nfosol.com (Rajesh) writes:
>>
>> >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;
>> }
>
>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
>implementati on 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.

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
circumstance s.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:

In <lz************ @cts.com> Keith Thompson <ks*@cts.com> writes:

[...]

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.

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.

--
Keith Thompson (The_Other_Keit h) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"