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
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
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.
"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.
[...] 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.
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.
YOU are entitled to YOUR opinion. As far as 'describing' you, what comes to mind is 'stubborn' which is not necessarily bad.
i just hope that the OP has not gotten the impression from your postings that char and unsigned char is the same.
Have fun,
The whole point is:
There are 3 distint char types
char unsigned char signed char
They are 3 different types. No matter how they are interrepted, none of the 3 types are "the same".
achar may have the same range of values as either signed char or unsigned char, and this is up to the implementer of the compiler to decide, and possibly if they are nice allow you to change the default.
Even if char has the same range of values as unsigned char, they are not the same type, therefore the warning that the compiler generated for them.
Also even if char has the same range of values as signed char, they are not the same type and this would also generate a warning (at least in keil/Realview ARM compiler)
It appears (erik with a k) that your compiler (non ARM, looks like 8051) defaults to char and signed char having the same range, but they still are not the same type. Other compilers (as the standard "clearly" states) may and do chose char to have the same range as unsigned char, but still they are not the same type.
do chose char to have the same range as unsigned char, but still they are not the same type.
This is pure language and the following is not 'you are wrong' just another (I think equally valid) interpretation of the language
"do chose char to have the same range as unsigned char, which makes them the same"
No.
The char type is NEVER the same type as unsigned char or signed char.
They are 3 different types. They are not the same
char is defined to have the same range as signed char or unsigned char, but not to be the same type as.
The problem (Eric with a C) had was that the types unsigned char and char where mixed and the compiler was giving warnings (because they are not the same type).
Becuase we set the default to interrpret char as having the same range as unsigned char, we could ignore the warnings.
I'm sure he doesn't share your talent for misunderstanding.
Let me see if I understand you.
This particular compiler treat unsigned char and char the same way, but because someone may assume that it is done the other way the compiler complain when you mix the two.
Thus, if your 'understanding' of (un)signed char and char is the same as the compiler it is safe to ignore the warning. (I disagree here: I would never consider it safe to ignore a warning - but that is a different story)
am I right?
When accused of being ignorant rather than getting a simple statement (maybe with a reference), I have no reason to put any credence to the response from the accuser. Robert, since you gave me a 'sane' explanation, I will admit that my 'knowledge' based on a statement in (was it) '87 by the instructor of the C class I then took: "char and signed char is the same" may have changed since then/been wrong. He actually added "to be clear always state (un)signed char, never just char". I have NEVER used just 'char' (I like to be specific as well) thus there has never been a reason to believe that statement from '87 and Kochans seeming agreement with it was incorrect.
I wonder if Jack Sprat peruses several books to verify his knowledge before posting, I doubt it, so it is very possible that at some time it will be him that is "the grossly opinionated that show his ignorance with such panache"