Keil C does not support

The position of "volatile" is the aim.You can try

typedef const long volatile *PVLONG;

typedef const volatile long *PVLONG;

And if there is no "const", it's also OK.

OK, I'll look in a spec soon. And, it is not the side-effect of xdata.The following line can not be compiled either:

typedef const long volatile *pclVal0;
typedef const char volatile *pclVal1;

typedef long volatile *pclVal0;
typedef char volatile *pclVal1;
typedef const short volatile *pclVal2;
typedef const int volatile *pclVal3;
typedef const volatile long *pclVal4;
typedef volatile const long *pclVal5;

I *think* that the following:

typedef const long volatile *pclVal0;
typedef const char volatile *pclVal1;

are correct and should compile. The fact that int and short work makes me suspect that there is something going wrong due to to the fact that:

const abc;

is equivalent to:

const int abc;

ie the compiler's 'default to int' mechanism is being incorrectly invoked.

Interestingly the same problem occurs with:

volatile long const *abc;

just curious How can something that is constant be volatile

Erik

"just curious How can something that is constant be volatile"

We flogged this to death before. In the 'C' programming language const!=constant.

Just accept it.

"How can something that is constant be volatile"

Yes, it appears contradictory at first sight, but is actually perfectly reasonable:

'const' simply tells the compiler to give a warning on any attempt to write to the symbol; it means "read-only" - it does not mean "constant!"

The obvious example would be a read-only memory-mapped register - you'd use 'const' to prohibit writes to it, and 'volatile' for the usual reasons.

Agree on upstairs. I just describe a read-only register outside the MCU. So, it must be const and volatile. See the code below:

#include "TYPEDEF.H"

typedef volatile UINT32 xdata		*PVX32;
typedef const volatile UINT32 xdata	*PCVX32;

//register sets
#define CONTRL_REG (*((PVX32) 0x0600))//Control Register
#define INTRPT_REG (*((PVX32) 0x0604))//Interrupt bits

typedef const volatile *PVINT;

typedef const volatile long *PVLONG;

typedef const long volatile *PVLONG;

Just a guess
VC sell millions of copies
Keil sell thousands of copies

just visualize the budgets

So, if some insignificant thing arise and there is a simple way to handle ir shut up and let Keil with the limited budget concentrate on significant issues.

Erik

"So, if some insignificant thing arise and there is a simple way to handle ir shut up and let Keil with the limited budget concentrate on significant issues."

I see. So when you find bug in your software you think the best approach is to find a workaround and ignore it rather than investigating whether it has wider implications than those you have observed for a particular test case?

So when you find bug in your software you think the best approach is to find a workaround and ignore it rather than investigating whether it has wider implications than those you have observed for a particular test case?

No, absolutely not, However dragging out "VC can this, why can Keil not" is ridiculous.

I do not expect Keil to consider VC "the standard", C for the '51 is a quite different animal than C for the PC.

Anyhow, this hardly qualify as a "bug", requiring parametres in a certain order could, at most, be labelled an inconvenience.

If I found an error, not an inconvenience, I would definitely press the issue.
However an inconvenience should, of course, be brought to the attention to Keil, but harping on it as a disaster is ridiculous.

Again I did not post as to the issue being mentioned, which it should, but to it being dragged out. I woukd expect Keil to check if this existed in a wider context and either document "the sequence MUST be" or allow random sequencing of keywords.

Erik

addendum:

the statement is "Keil C does not support", had it been "Keil C produce erroneous code" I would, of course, not have been of my stated opinion.

Erik

"I do not expect Keil to consider VC "the standard", C for the '51 is a quite different animal than C for the PC."

Nobody expects Keil to consider VC the standard. We do expect them, however, to conform to the ANSI standard unless there is a good reason not to do so.

"Anyhow, this hardly qualify as a "bug", requiring parametres in a certain order could, at most, be labelled an inconvenience. If I found an error, not an inconvenience, I would definitely press the issue."

const int volatile abc; //Compiles
const long volatile abc; //Doesn't compile

You don't think that's a bug? Or an error?

"Again I did not post as to the issue being mentioned, which it should, but to it being dragged out. I woukd expect Keil to check if this existed in a wider context and either document "the sequence MUST be" or allow random sequencing of keywords."

The whole point of having an ANSI 'C' compiler is so that anyone who can write ANSI 'C' can use it. The whole thing becomes pointless if you allow compiler writers to deviate arbitrarily from that standard.

Would you consider it acceptable to have this ordering provided it were documented?

42 int = volatile abc;