Bug in Imagecraft AVR?

On 14 Nov 2003 18:15:46 GMT, "Mark A. Odell" wrote in comp.arch.embedded:

The latest C standard was approved four years ago last month. It now includes a standard header, , that defines a standard syntax for naming exact width integer types:

int8_t, uint8_t, int16_t, uint16_t, and so on.

They're not the prettiest I have ever seen, but they are standard, and it's pretty easy to make your own stdint.h header to use them.

We've made them for TI DSP's (no *8_t types!), Motorola HS12, Visual C++, among others. In fact, it so happens that the stdint.h header that comes with ARM's ADS works just fine with Visual C++, right down to supporting signed and unsigned __int64 as int64_t and uint64_t.

Try using the standard ones for your next project, it will ease porting.

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein
Loading thread data ...

You probably need to cast your unsigned char* pointers to (char*) for the library routines.

Yes, the integer promotion can mess this up. To code it with type char, I would do

#define EXIT_KEY '\xF1' ... void process (char k) { printf ("key is %02x\n", (unsigned char)k);

Thad

Reply to
Thad Smith

Wrong - "char" should *never* be considered signed or unsigned. If you want to write code that is readable, reliable, and works, then you should always specify "signed char" or "unsigned char". I've used ImageCraft's avr compiler for years, and I have no idea what the signedness of a plain "char" is on that compiler.

Reply to
David Brown

want

always

"char"

Unsigned, as I found out the hard way and read in the helpfile afterwards.

Meindert

Reply to
Meindert Sprang

And it could be signed in the next version of the same compiler. Don't rely on char being either signed or unsigned.

Reply to
Sheldon Simms

[...]

Wouldn't help. Character literal constants have type int. And even if they didn't, you still wouldn't know if plain char is signed or unsigned. And if plain char is signed, the value would be sign-extended before the compare, which would then always be true. And the program would loop forever. As before.

To fix it, you need to make the variable "key" unsigned char or int. Either that, or cast it as unsigned char in the comparison.

This wouldn't do anything at all. Nothing that would be visible, anyway.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

.. and his compiler was to shy to warn him ;-)

"Warning: comparison is always false due to limited range of data type"

is the msg you get from gcc in cases like this.

OTOH, he should better use a language in which these type of statements doesn't compile at all..

Bernd

--
There are some things that money can't buy...you have to download them
from gnu.org
Reply to
Bernd Trog

Actually, our compilers DO give similar warning. He ignored it :-)

-- // richard

formatting link

Reply to
Richard F. Man

Yes, character constants have type int. This works with either signed or unsigned default char type. That is my point.

No. If char is signed, Both key and EXIT_KEY would be signed and both would be sign extended when comparing. If key were the EXIT_KEY value, (key != EXIT_KEY) would be false.

No, not really.

Here is a test program for elucidation. Compile and run it with both default signed and unsigned options.

#include #define EXIT_KEY '\xF1' int main(void) { char c; c = EXIT_KEY; printf ("c=%d, EXIT_KEY=%d, c==EXIT_KEY=%d\n", c, EXIT_KEY, c==EXIT_KEY); return 0; }

Wrong. If the cast isn't applied and char is signed by default, k is promoted to int, which will cause a sign extension if INT_MAX >

CHAR_MAX. Strictly speaking, there is a mismatch of type between an int parameter and an expected unsigned int. More practically, if k is not cast to unsigned char before promotion, you will see the full width of an unsigned int with added bits of sign extension when k is negative, rather than an unsigned char.

Here's another program for you, which shows a difference when char is signed (and 8 bits):

#include #define EXIT_KEY '\xF1' int main(void) { char c; c = EXIT_KEY; printf ("c=%02x (unsigned char)c=%02x\n", c, (unsigned char)c); return 0; }

Thad

Reply to
Thad Smith

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.