effect of volatile in this example

[joshc]

void foo(void) {
unsigned int *ptr = (unsigned int *)0x200;

*ptr = 4;

return;
}

I do most of my work in embedded environments so I'm not so strictly
familiar with all of the Standard, so maybe setting up a pointer to
0x200 like I did is undefined behavior. If not, can a conforming
implementation optmize the assignment statement above out if I declare
the pointer like I've done without the volatile qualifier?

Thanks,

Josh

 

[Raman]

void foo(void) {
unsigned int *ptr = (unsigned int *)0x200;

*ptr = 4;

return;

}

I do most of my work in embedded environments so I'm not so strictly
familiar with all of the Standard, so maybe setting up a pointer to
0x200 like I did is undefined behavior. If not, can a conforming
implementation optmize the assignment statement above out if I declare
the pointer like I've done without the volatile qualifier?

Thanks,

Josh

I Thing there is nothing wrong, as far as standrad is concerned. But,
it do have dependency on the Platform( may be address 0x200 is
reserved by OS, So you are interfaring with internals ). Not using
Volatile, is not going to harm either.But, If you need more
information, Describe exactly what happened on execution of this
program.
Thanks,
Raman Chalotra

 

[Eric Sosman]

void foo(void) {
unsigned int *ptr = (unsigned int *)0x200;

*ptr = 4;

return;
}

I do most of my work in embedded environments so I'm not so strictly
familiar with all of the Standard, so maybe setting up a pointer to
0x200 like I did is undefined behavior. If not, can a conforming
implementation optmize the assignment statement above out if I declare
the pointer like I've done without the volatile qualifier?

The assignment can be removed only if the implementation
can determine that it has no necessary side-effects. In this
case, storing the value 4 in the referenced location is a side-
effect, so the implementation would somehow need to know that
the side-effect is unnecessary, that is, that the stored value
cannot in any way influence the program's output. Since some
of the other modules of the program might not be compiled or
even written until the day after tomorrow, that sort of thing
requires a degree of prescience not usually found. You should
be safe at least until Carnac the Magnificent goes into the
compiler-writing business.

But if there's something special about the location 0x200 --
it's an I/O register or some such -- why not use `volatile' in
the first place and stop worrying? That's one of its purposes,
and it fits your need, so ... It's true that implementation-
defined fog surrounds most uses of `volatile', including this
one, but compiler writers have an incentive to "do the right
thing" as far as they're able.

 

[David T. Ashley]

You should
be safe at least until Carnac the Magnificent goes into the
compiler-writing business.

And if Carnac really is magnificent, there shouldn't be a problem. He
should be able to determine the implications of all side-effects.

 

[CBFalconer]

void foo(void) {
unsigned int *ptr = (unsigned int *)0x200;

*ptr = 4;
return;
}

I do most of my work in embedded environments so I'm not so strictly
familiar with all of the Standard, so maybe setting up a pointer to
0x200 like I did is undefined behavior. If not, can a conforming
implementation optmize the assignment statement above out if I
declare the pointer like I've done without the volatile qualifier?

The thing you would declare volatile is *ptr. ptr itself would not
be volatile.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Nick Keighley]

I Thing there is nothing wrong, as far as standrad is concerned.

nothing wrong? It is undefined behaviour, which an implementation
is permitted to do something sensible with if it desires. But it is
not
*required* to do anything sensible.

But,
it do have dependency on the Platform( may be address 0x200 is
reserved by OS, So you are interfaring with internals ). Not using
Volatile, is not going to harm either.But, If you need more
information, Describe exactly what happened on execution of this
program.

--
Nick Keighley

Unicode is an international standard character set that can be used
to write documents in almost any language you're likely to speak,
learn or encounter in your lifetime, barring alien abduction.
(XML in a Nutshell)

 

[Guest]

nothing wrong? It is undefined behaviour,

The result of a conversion from an integer to a pointer type is
implementation-defined. Depending on that implementation-defined
result, it is possible that there is no undefined behaviour on the
specific implementation (even though there would be on others).

 

[joshc]

The assignment can be removed only if the implementation
can determine that it has no necessary side-effects. In this
case, storing the value 4 in the referenced location is a side-
effect, so the implementation would somehow need to know that
the side-effect is unnecessary, that is, that the stored value
cannot in any way influence the program's output. Since some
of the other modules of the program might not be compiled or
even written until the day after tomorrow, that sort of thing
requires a degree of prescience not usually found. You should
be safe at least until Carnac the Magnificent goes into the
compiler-writing business.

But if there's something special about the location 0x200 --
it's an I/O register or some such -- why not use `volatile' in
the first place and stop worrying? That's one of its purposes,
and it fits your need, so ... It's true that implementation-
defined fog surrounds most uses of `volatile', including this
one, but compiler writers have an incentive to "do the right
thing" as far as they're able.

Hi Eric,

Thanks for your response. The reason I asked this question was because
during an interview I was asked what volatile was and why you needed
to use it. I explained all the reasons and then I was basically
presented with the example above. I argued that it wasn't necessary in
this case for the reason you mentioned about side-effects, but the
interviewer argued otherwise.

Once again, thanks for the detailed reply.

Josh

 

[joshc]

The thing you would declare volatile is *ptr. ptr itself would not
be volatile.

Yes, that is what I meant to say. Thanks for the correction.

 

[Richard Bos]

The assignment can be removed only if the implementation
can determine that it has no necessary side-effects.

Or that it has undefined behaviour. Integers with a size that is
relatively prime to 0x200 are scarce to the point of non-existence and
AFAIAA upto and including that point, but they are legal; and therefore,
so are integers for which 0x200 is converted into a badly aligned
pointer. (Come to think of it, I don't see that requiring ints to be
aligned to odd addresses is illegal. So even with the most commonly
expected conversion of 0x200 to int pointer type and with 2-byte ints,
(int *)0x200 could in theory be a non-aligned pointer.)

Richard

 

[Eric Sosman]

Or that it has undefined behaviour. Integers with a size that is
relatively prime to 0x200 are scarce to the point of non-existence and
AFAIAA upto and including that point, but they are legal; and therefore,
so are integers for which 0x200 is converted into a badly aligned
pointer. (Come to think of it, I don't see that requiring ints to be
aligned to odd addresses is illegal. So even with the most commonly
expected conversion of 0x200 to int pointer type and with 2-byte ints,
(int *)0x200 could in theory be a non-aligned pointer.)

I'd written about this in my original reply on the thread,
but cut that part before sending on the grounds that it was an
unnecessary, hair-splitting, angel-counting departure from the
real question at hand. "Let it pass," thought I, "The O.P. is
asking about embedded environments where special needs abound
and this sort of dubious conversion is the only way to get things
done. Why drag in irrelevancies?"

You'd think I'd know better. I've been following c.l.c. for
twenty years, and should have learned that while irrelevancy may
not be the meat and potatoes of its diet, it is at least the
eggplant.

In the interest of balanced nutrition, then:

1) Converting an integer to a pointer produces a result
that is implementation-defined. No undefined behavior!

2) The implementation-defined result need not be valid.
It may be improperly aligned, it may "point to nowhere," it
may even be a trap representation. (In which case, the result
is not even a "value," properly speaking.)

3) If the result is a trap representation or is incorrectly
aligned, the act of assigning it to a pointer causes undefined
behavior.

4) If the result is an invalid value, the attempt to use
it to reference an object causes undefined behavior.

N) THEREFORE: The O.P.'s fear that the conversion is undefined
are groundless; it's implementation-defined. The possibility of
U.B. doesn't arise until *after* the conversion. What a relief!
"Don't worry, King Louis, nobody's going to shoot you."