[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Re: [avr-gcc-list] Odd itoa/strrev problem with
From: |
E. Weddington |
Subject: |
Re: [avr-libc-dev] Re: [avr-gcc-list] Odd itoa/strrev problem with |
Date: |
Mon, 16 Jun 2003 15:38:22 GMT |
> At 15 Jun 2003 03:39 Josh Pieper wrote:
> > I haven't tried reduce this problem to the most simple
test case yet,
> > but was wondering if anyone has seen something similar
and has a tip.
> > I'm using itoa on an ATmega8535 with the UART receive
and timer 0
> > compare interrupt enabled. Every 20 or 30 itoa's, it
returns a string
> > that is reversed. i.e. instead of "-49" it will
return "94-".
> >
> > I'm using a cvs snapshot of avr-gcc and avr-libc dated
20030512.
> >
> > I have already verified that there is no way that the
stack is
> > overrunning data, and I am using SIGNAL to define the
interrupt
> > handlers. Any quick tips, or should I reduce it to a
simple test case
> > and post that?
> >
>
> Good afternoon!
>
> I have checked up work "itoa" on the plate with ATmega163.
> Works correctly, including "-49".
>
> But on realization (itoa.S) there are two remarks:
>
> 1. There is no clearing "T" in a case when "radix" it is
not equal 10. It
> results, for example, in the following:
> itoa(0, s, 10) --> "0"
> itoa(-2, s, 8) --> "177776" (T was 0)
> itoa(-2, s, 10) --> "-2" (T set 1)
> itoa(-2, s, 8) --> "-177776"
>
> 2. Erroneous "radix" results in unpredictable
consequences: a call "strrev"
> with "value" as the address of a string. Apparently,
instead of:
> cpi r_radix, 2 ; no radix < 2
> brlt terminate
> it is necessary to put:
> cpi r_radix, 2 ; no radix < 2
> brlt n_terminate
>
> Best wishes.
>
Could you fill out a bug tracker at the avr-libc project
page for this? It would be greatly appreciated. Thay way it
doesn't get lost in the cracks.
Eric
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [avr-libc-dev] Re: [avr-gcc-list] Odd itoa/strrev problem with,
E. Weddington <=