Keil C does not support

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;

"For two qualified types to be compatible, both shall have the identically qualified version
of a compatible type; the order of type qualifiers within a list of specifiers or qualifiers
does not affect the specified type." from ISO/IEC 9899:1999
And I can not find more.

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

You don't think that's a bug? Or an error?
Neither. I consider it an insignificant inconvenience which, of course, should be fixed, but not necessarily "yesterday.

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.
well, if that is your opinion, let us remove DATA, XDATA etc.

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

42 int = volatile abc;
In a low volume product, absolutely. Keil is doing a great job of making the compiling bug free and reasonably efficient, if a glitch of a certain odd sequence of parametres produce "does not compile" is that significant compared to "xxx,xxx produce the wrong result"

I never said "forget this", just don't get your knickers in a knot becuse you have to change the sequence of two words.

Do I expect Keil to fix this eventually, sure, but once Keil knows about it stop whining

Erik

TC 2.0 and HI-TECH C for 8051 are both support this:

typedef const volatile long *pLONG;

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

Neither. I consider it an insignificant inconvenience"

Excellent! I shall stop calling bugs in my code 'features' and start calling them 'insignificant inconveniences' from now on.


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

well, if that is your opinion, let us remove DATA, XDATA etc."

Don't be silly. The standard permits extensions provided they are documented. Are you unable to see the difference?

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

42 int = volatile abc;

In a low volume product, absolutely."

So, you would be quite happy if you bought a 'C' compiler then discovered it actually compiled a language that wasn't 'C'?

"just don't get your knickers in a knot becuse you have to change the sequence of two words."

I think you're the one with his knickers in a knot!