put const variables into code-segment

Staffan:

The fact that Keil use an oxymoron ("constant variable") does not make it correct.

Erik

Staffan:

The fact that Keil use an oxymoron ("constant variable") does not make it correct.

Erik

"The fact that Keil use an oxymoron ("constant variable") does not make it correct."

I'm afraid you're wrong.

In 'C' a const qualified type is not necessarily unmodifable. All that is required is that the variable is not modified as an lvalue. The compiler is allowed but not required to place a const qualified object in read-only storage, and is prevented from doing so if the volatile qualifier is always present.

Consider:

const volatile int xdata reg _at_ 0x100;

Notice that no initialiser is present.

The behaviour of the const keyword in C++ is different and seems closer to your expectations.

my reference states:
.... So the declaration

const int x5 = 100;

declares x5 to be a constant integer(that is, it won't be set to anything else during the program's execution)

My emphasis

Erik

"const int x5 = 100;

declares x5 to be a constant integer(that is, it won't be set to anything else during the program's execution)"

Try this:
int *ptr=&x5;
*ptr=42;

And this:
extern const volatile int a;

As for terminology:
5 //Integer constant
#define X 5 //Integer constant
int a; //Integer variable
const int a; //Constant integer variable

Compile this under 'C' and 'C++' to see the difference between a const in C++ (which is a constant) and a const in 'C':
const int a;

I can take a knife and use it to peel an apple. I can use the same knife to kill someone.

Knives are legal, does that mean that using it to kill someone is legal too?

One of the most frequent objections to C is that it let you screw it up more than any other language (i.e. it does not stop you from duing unintended things). The ANSI C standard and K&R clearly intend that a const is read only. If it were not so, then why make it legal to locate it in ROM.

It may be fun to find the "holes" in 'C' such as writing to const, I fail to se either the purpose or the value thereof.

Erik

" The ANSI C standard and K&R clearly intend that a const is read only."

Unless it is volatile.

"It may be fun to find the "holes" in 'C' such as writing to const, I fail to se either the purpose or the value thereof."

I don't wish to find holes in 'C'. I'm just trying to get you to understand that there is a difference between a constant and a const qualified variable.

Unless it is volatile.

Even a volatile const (if that's allowed at all...) object is still read-only --- for the C program. What other elements of the system might do to it is beyond the scope of not just the 'const' keyword, but of the entire language standard.

"Even a volatile const (if that's allowed at all...)"

It is.

"object is still read-only --- for the C program."

No. An interrupt service routine can modify that volatile const object.

"What other elements of the system might do to it is beyond the scope of not just the 'const' keyword, but of the entire language standard."

The draft C99 standard I have to hand gives the above as an example.

"An interrupt service routine can modify that volatile const object."

What, so you mean the object is declared without const for the ISR, but with const for main() - thus allowing the ISR to write it, but main() to only read it?

That sounds like a good idea - I shall have to bear it in mind.

What, so you mean the object is declared without const for the ISR, but with const for main() - thus allowing the ISR to write it, but main() to only read it?

That sounds like a good idea - I shall have to bear it in mind.

From what I recall from when const was introduced...

The intention of const was to provide a means of protecting variables from modification outside the "write scope". In an ideal world, the variable would be local but would be passed to functions as a const argument (much like the string functions in the C library).

However, I'm pretty sure the same can be done with global variables. Places that must modify the const variable must use some typecasting trickery to make things work (by either creating a pointer to the const or by typcasting the variable without the const qualifier).

However, in reality, it's much easier to just use const on function arguments. This makes it clear to someone which arguments may be affected by looking only at the function prototype.

Jon

Well, that's no argument, since a) interrupt service routines can't be written in the "C" that provides the applicable definition of these terms (i.e. the ISO C standard), and b) even if they could, there's no conforming way to get access to a const object that would allow the ISR to write to an object the main code can't. Whichever way you try (pointer casts, trick unions): you always cross an "undefined behaviour beyond this line".