This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Keil C does not support

Keil C does not support this line:

typedef const UINT32 volatile xdata *PCVX32;
it just support this way
typedef const volatile UINT32 xdata *PCVX32;
but other ANSI C compilers support both.
Is it a bug or something else?

Parents Reply Children
  • "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
    

    And, oh my god! This can be correct on Keil C and VC.
    typedef const volatile *PVINT;
    
    I think the default of "const" must be "const int".
    But why this can be compiled on Keil:
    typedef const volatile long *PVLONG;
    
    while this can not:
    typedef const long volatile *PVLONG;
    
    VC support both.

  • 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;
    
    I think most of C compilers can accept this.
    And I just find out the matter that Keil does support it. So I share it to everyone. I don't have any other thought. Keil C is a great product and I love it. Also, nothing is perfect.

  • "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!

  • Staffan:

    let me repeat from a previous post
    "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.".

    thus, please stop dragging it out.

    Erik

  • "Staffan"

    Try again.

    "let me repeat from a previous post
    "Again I did not post as to the issue being mentioned, which it should, but to it being dragged out."

    Perhaps you should restrict your posts to technical contributions?


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

    And I have explained to you why they cannot, and would not want, to do that.


    "thus, please stop dragging it out"

    I have no desire to drag anything out. Your contribution to this thread contained errors, I corrected them. Deal with it.

  • Please state fully, you shouls post
    Your contribution to this thread in my ponion contained errors.

    That we do not agree does not make my opinion erroneous.

    Erik