David Brown wrote:
Horse and saddle to that guy who find what is wrong in below code:
unsigned int oct2int(const char* oct){
i know it's fun implementing the own algorithms, but i would take that
one from the c library, this time ;-)
#include <stdlib.h>
long n;
n = strtol("123", NULL, 8);
that one can parse numbers of any base (0 == autodetect)
unsigned int ret = 0;
int i,j=0,k,length = strlen(oct);
for(i=length-1;i >= 0;i--){
if((k=(oct[i]-'0')) > 0) ret += 1<<(3*j) * k;//8 = 2^3
j++;
}
return ret;
}
Did you learn to program at http://www.de.ioccc.org/main.html ?
yep that site is fun :-)
> What's
wrong with the code is that is is illegable - in my book, that makes the
code incorrect regardless of what happens when you try to compile and run
it. It's also horribly inefficient (you are scanning the string twice,
using an unnecessary multiply, and using an unnecessary variable shift) -
that's just not how you write code for embedded systems. I'd post an
example implementation, but Bill beat me to it.
And if you want to post generated assembly (something that is often useful
to aid debugging), avoid flags that do loop unrolling or inlining, since
they generate far more code to look through, and include the flags used.
Note - it is possible that you've hit a bug in the compiler here somewhere,
since you should not need to explicitly re-enable the interrupts. Can you
i just looked at the gcc internals and the posted source, looks fine on
first sight.
it generates hwmul code in the following form:
push r2
dint
nop
.....
pop r2
which means it should restore your previous interrupt setting, but it
uses two bytes on the stack.
chris
cut down the code to a minimum that still displays the interrupt problem,
and then post the code, generated assembly, and information about the
compiler version and compile flags?
