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

Compile char as an unsigned char

Hello,

Can anyone tell me how to instruct Keil to compile char's as unsigned char's by default?

I know that there are some help topics on this issue, but they seem to be giving a precompiler directive to tell the compiler to always compile char's as signed char's....

Thanks!
Eric

Parents
  • Can anyone tell me how to instruct Keil to compile char's as unsigned char's by default?

    translation: "Can anyone tell me how to instruct Keil to abolish following the C standard"

    It's quite delightful when the grossly opinionated show their ignorance with such panache.

Reply
  • Can anyone tell me how to instruct Keil to compile char's as unsigned char's by default?

    translation: "Can anyone tell me how to instruct Keil to abolish following the C standard"

    It's quite delightful when the grossly opinionated show their ignorance with such panache.

Children
  • It's quite delightful when the grossly opinionated show their ignorance with such panache.

    Maybe not 'ignorance' but 'simplification'. Yes, there is a lot about guaranteeing sign extension and such, but nevertheless

    The C standard states clearly that "signed char" is same as "char" and concluding from that that 'unsigned char' is different from 'char' does not take an Einstein.

    now, explain this difference

     120   1      unsigned char Usevenx = 0x74;
     121   1      unsigned char Ueightx = 0x82;
     122   1      char sevenx = 0x74;
     123   1      char eightx = 0x82;
     124   1      U8 helper;
     125   1
     126   1      if (Ueightx > Usevenx)
     127   1      {
     128   2        helper = 7;
     129   2      }
     130   1      if (eightx > sevenx)
     131   1      {
     132   2        helper = 8;
     133   2      }
     134   1
    0000 750074      R     MOV     Usevenx,#074H
                                               ; SOURCE LINE # 121
    0003 750082      R     MOV     Ueightx,#082H
                                               ; SOURCE LINE # 122
    0006 750074      R     MOV     sevenx,#074H
                                               ; SOURCE LINE # 123
    0009 750082      R     MOV     eightx,#082H
                                               ; SOURCE LINE # 126
    000C E500        R     MOV     A,Ueightx
    000E D3                SETB    C
    000F 9500        R     SUBB    A,Usevenx
    0011 4003              JC      ?C0018
                                               ; SOURCE LINE # 127
                                               ; SOURCE LINE # 128
    0013 750007      R     MOV     helper,#07H
                                               ; SOURCE LINE # 129
    0016         ?C0018:
                                               ; SOURCE LINE # 130
    0016 D3                SETB    C
    0017 E500        R     MOV     A,sevenx
    0019 6480              XRL     A,#080H
    001B F8                MOV     R0,A
    001C E500        R     MOV     A,eightx
    001E 6480              XRL     A,#080H
    0020 98                SUBB    A,R0
    0021 4003              JC      ?C0019
                                               ; SOURCE LINE # 131
                                               ; SOURCE LINE # 132
    0023 750008      R     MOV     helper,#08H
                                               ; SOURCE LINE # 133
    0026         ?C0019:
    

    so "char' and 'unsigned char is the same???

    Erik

  • The C standard states clearly that "signed char" is same as "char"

    No, it doesn't, and it never did.

    Quoting C99, 6.2.5, paragraph 15 (emphasis mine):

    The three types char, signed char, and unsigned char are collectively called
    the character types. The implementation shall define char to have the same range,
    representation, and behavior as either signed char or unsigned char.
    

  • The C standard states clearly that "signed char" is same as "char" and concluding from that that 'unsigned char' is different from 'char' does not take an Einstein.

    Perhaps it's time to actually read the standard?

  • maybe it is updated, what I have is
    signed char, Same as char, except ensures that sign extension will occur as a result of integral promotion

    Erik

  • maybe it is updated, what I have is
    signed char, Same as char, except ensures that sign extension will occur as a result of integral promotion

    Which paragraph in which version of the 'C' standard is that from?

  • Which paragraph in which version of the 'C' standard is that from?

    It is from the ANSI C Language summary in Stephen G. Kochan: "programming in ANSI C ISBN 0-672-48408-0 copyrighted 1998. Page 393 paragraph 4.2 Basic Data Types.

    Now, before you attack the source, I'll let you know that 10thousands of lines of working C has been cranked out based on that book by me, not to even guess the amount by others. Someone mentioned (here?) about communicating via e-mail with Kochan, so, if you have an issue with the book, take it up with him. I have succesfuuly coded based on that as the truth for years.

    Erik

  • "The C standard states clearly that "signed char" is same as "char"

    No, it doesn't, and it never did.

    Quoting C99, 6.2.5, paragraph 15 (emphasis mine): ..."

    C90 says the same thing, but in many more words. So now quoting C90, 6.1.2.5 "Types", paragraph 2:

    "An object declared as type char is large enough to store any member of the basic execution character set. If a member of the required source character set enumerated in 5.2.1 is stored in a char object, its value is guaranteed to be positive. If other quantities are stored in a char object, the behavior is implementation-defined: the values are treated as either signed or nonnegative integers."

    char and signed char are only equivalent in that they occupy the same amount of storage. C90 in the same section, paragraph 4:

    "An object declared as type signed char occupies the same amount of storage as a 'plain' char object."

  • "It is from the ANSI C Language summary ..."

    Use those books with The Standard!

    "The Standard" is the standard, not someones book interpreting The Standard. Those adjunct books, while making The Standard easier to digest, should not be used in isolation regarding standards issues -- Schildt's for certain, now maybe Kochan? In my opinion, it's better to have The Standard at your side too.

  • If you don't want to spend the small sum of $30 to buy from ANSI, you can get a working paper reflecting the current approved standard www.open-std.org/.../n1124.pdf from the working group's web page www.open-std.org/.../ .

  • Now, before you attack the source,

    No need to --- the book, as quoted, is correct. I see a need to attack your interpretation of it on two counts, though:

    1) you claimed "the C standard clearly states", when you apparently don't actually have a copy of that document, so you cannot actually know what it states and what it doesn't.

    2) your source said "same as [...], except", and you condensed that into a claim that the things were the same, changing the meaning rather drastically.

    I hope you apply logics a bit better than that in your daily work. As aggressively as you often state things as truth in this forum, you had better be able to back up your claims.

  • C90 says the same thing, but in many more words. So now quoting C90, 6.1.2.5 "Types", paragraph 2:

    Just for the record: all those "many more words" are still present in C99 (section 6.2.5 now), too. And I think C90 had wording equivalent to 6.2.5 paragraph 15. I chose not to quote the former because the latter gets to the point quicker.

  • "Just for the record: all those "many more words" are still present in C99 (section 6.2.5 now), too."

    To be precise, that's paragraph 3 of the C99 section.

    "And I think C90 had wording equivalent to 6.2.5 paragraph 15. I chose not to quote the former because the latter gets to the point quicker."

    Only for the first sentence. The second sentence was added in C99.

    My referencing C90 is so folks don't throw back some argument about Keil's tools not being C99 compliant. For this particular C issue, C99 or C90, nothing has changed.

  • [...] so, if you have an issue with the book, take it up with him.

    Now you're blaming the book! Can't you just accept that you're wrong?

  • Now you're blaming the book!
    No, I am not 'blaming' the book, but if a brief, non-exhaustive explanation is not good enough for you, that is not MY problem. If you believe that Kochan commited a deadly sin by abbreviating as he did, you SHOULD take it up with him.

    Instead of posting 'incomplete' if the brief was not good enough for you, why did you not post 'here it is expanded'. You have posted NOTHONG showing that the brief was 'wrong' only kept on that it was not exhaustive enough for you.

    If the 'brief' information is true, what is your issue? that the explanation is not long enough ?

    The OP wanted char to compile as 'unsigned char' I replied "that will not work" and, as my example show, it will not.

    If I were 'wrong' in quoting an extract as 'the standard', sorry, the 'extract' has served me well for a decade or more and, as it does show that char does not compile as unsigned char, the OPs question is answered.

    Erik

  • You have posted NOTHONG showing that the brief was 'wrong' only kept on that it was not exhaustive enough for you.

    Others have already explained to you what you got wrong and expanded in detail. There is little point in my rehashing the same thing. In spite of their clear explanations you still seem determined that the fault cannot lie with you, and that I should take issue with the author of a book I've never read (bar one sentence quoted out of context, originally misattributed to the 'C' standard).

    I originally described you as ignorant, I'm beginning to suspect that stupid would be more appropriate.