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.
To the best of my knowledge the 'if' below should test 2 bytes. What is wrong here
void funct(unsigned char *valptr) { if (((unsigned int)*valptr) != 0) generates 0012 8F82 MOV DPL,R7 0014 8E83 MOV DPH,R6 0016 E0 MOVX A,@DPTR 0017 60F9 JZ ?C0047
*valptr = (unsigned long) 0 ;
The generated code is perfectly correct. In the first example, the condition is true if (*valptr) is nonzero, whether you convert it to unsigned int or not. The compiler is right here. The second example is essentially about the same thing. Regards, Mike
Sorry, the second example is not about the same thing. In an assignment, the value of the right operand is converted to the type of the left expression. So nothing unusual here as well. - Mike
"The generated code is perfectly correct. In the first example, the condition is true if (*valptr) is nonzero, whether you convert it to unsigned int or not" If valptr point to an int, how can !=0 be true if ONE BYTE is (non)zero. If the first byte is zero ond the second byte of the int is non-zero, the test should fail. The second half of the int is never tested. (the snippet is complete - only one byte is tested) Re the second example: How can STORING a long be accomplished by storing a byte. Erik Erik
Ok Mike, second example (U32) *XcurrListBeg = 0x00000000; took care of it Thanx, Erik
I thought you were in search of a bug in the compiler :-) If you needed to test two bytes you should have declared valptr as a pointer to int, or convert it to a pointer to int before applying the * operator, not after. Regards, Mike
In other words, here is the code to sort out the thing:
void funct(unsigned char *valptr) { if ((*(unsigned int*)valptr) != 0) // ...
Thanks Mike, I'm up and running. Erik PS: should the failed attempts not have generated an error or at least a warning.
"should the failed attempts not have generated an error or at least a warning." As I've noted before, this is both the strength and the danger of pointers in 'C'! With pointers, the ethos of the 'C' language is very much, "you asked for it; you got it!" This is particularly true of embedded cross compilers, which tend to be relatively light on the amount & detail of their diagnostics. This is where tools like lint come in. Passing your code through a "big" compiler (eg, MSVC, Borland) will often elicit more detailed diagnostics.