Re: volatile Info

crisgoogle <crisgoogle@xxxxxxxxx> writes:
[big snip]
First off, I totally agree that this is all rather academic unless
you actually own a DS9K.

And I can't quite put my finger on what I'm trying to get at here,
so bear with me =)

Let's say that there _is_ some mechanism by which an object's value
may change, independently of what the abstract machine would otherwise
dictate. Modifying your example above:

/* assume that this is an implementation-defined memory-mapped
register that _ought_ to be treated as volatile. */
int *reg = 0x4000

Since there's no implicit conversion from int to int*, you need a cast
(and a semicolon):

int *reg = (int*)0x4000;

The behavior of accessing an int object at address 0x4000 is
undefined. There might not be accessible memory at that location;
dereferencing reg could easily cause the program to crash. (If you
don't think it's UB, feel free to show us where the standard defines
the behavior of accessing *(int*)0x4000.)

#include <stdlib.h>

/* The parameter here _ought_ be declared as volatile. */
int square(int *x) {
return *x * *x;

int main(void) {
*reg = 10;
return square(reg) == 100 ? EXIT_SUCCESS : EXIT_FAILURE;

(I think I got that right).

In parallel to your explanation with your original example, I think
you're suggesting that the implementation is non-conforming if
this program returns EXIT_FAILURE.

Does this code exhibit undefined behaviour? Unless I made a mistake
or missed something, I don't think so (ignoring overflow,
as usual).

I believe so; see above.

So it seems peculiar to me that the programmer can render the
implementation non-conforming by omitting the volatile in the
declaration of square().

That can't happen. If an object is volatile, any attempt to access it
without letting the compiler know it's volatile is either a constraint
violation or undefined behavior.

Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"