We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
printf("%#02bx",0xff); The above line of code does what I'd expect, ie it prints out "0xff". However, printf("%#02bx",0x00); prints out "0x000000000000000"..... for a very long time. The same happens for any value between 0x00 and 0x0f, 0x10 to 0xff work as expected. Is this a bug or am I being stupid? I'm using C51 V7.
Dafydd, how many characters you like to print out, two or four ("0x00")? It's four I think, isn't it. If you specify width in printf it means minimum number of characters to print out. I think that C51 compiler (C166 too) it does equally for you. True is, another compilers can solve this problem another way. I know Borland C++ Builder and it has different output. I don't know whether ANSI C norm specify how to solve this problem exactly but I suppose this problem depends on compiler impementation. Is it right? Regards, Vaclav
You're quite right, I did want to print out four characters: "0x00". Specifying %02 was my mistake. I was just worried that I'd stumbled across a bug that is dependant on the actual data being passed to printf() - this is exactly the sort of thing that gets through testing then fails in the field. I've just found a bug report on the Keil website: http://www.keil.com/support/docs/1190.htm which talks about this problem in C51 version 6 using 0xaa as data. If I compile their example in version 7 it works correctly - but only if the data is greater than 0x0f. The field width specifier is (as I understand it) the minimum field width to be used for output - specifying one that is too small is not considered an error condition, the output width should just be expanded as necessary. What I am certain about is that printf() should not hang up in an apparently endless loop! Thanks to all for testing this.
Keil have just advised me that this will be fixed in the next compiler revision.