[En-Nut-Discussion] printf() variants return 0.00 - stack alignment?

Philipp Burch phip at hb9etc.ch
Tue Aug 13 10:31:00 CEST 2013

Hi Harald!

On 08/13/2013 09:50 AM, Harald Kipp wrote:
> Hi Philipp,
> On 12.08.2013 19:03, Philipp Burch wrote:
>> since some time, I'm facing an annoying problem when it comes to
>> printing floating-point numbers using printf() variants (fprintf(),
>> sprintf(), etc.). The problem always looks the same, instead of the
>> actual value, there is only 0.000000 printed.
> http://old.nabble.com/Problem-with-ARM-floating-point,-again-td34961590.html

Oh, seeing that again I remember that I've even read this when you wrote 
the mail in the first place... So I suppose there is still no solution 
in sight, right?

>> As a (temporary) workaround, I would be happy with a simple function to
>> convert a float into a string (which should also be somewhat faster than
>> when working with doubles). Do you know a good implementation for this?
>> I don't need those many formats (g, e, f) as printf() has, all I need is
>> a variable number of decimal places and possibly automatic padding.
> I looked into this some time ago. I remember I found a few simplified
> routines, but none of them seem to work sufficiently well. In a next
> step I tried to figure out the required algorithms. Specifically the
> normalization (decimal shifting) is quite adventurous and the AT&T code
> is not easy to follow.
> Well, finally I came to the conclusion, that I better stay with the
> newlib implementation (some versions are working) and spend my time in
> fixed point routines, which would serve my needs better.

Ok, thanks. Calculations with those floats seem to perform well, so I've 
now implemented the way with the two ints as mentioned in your other post:

void ftoa(char* buf, const char* fmt, float num, int fact) {
   int prod = (int)(num * (float)fact);
   int integ = prod / fact;
   int fract = prod < 0 ? -prod % fact : prod % fact;
   sprintf(buf, fmt, integ, fract);

Not particularly nice, but works.

But what is most important for me atm: This is a problem that is only 
caused by this float printing stuff, right? So I don't need to fear that 
the same bug (or however it should be called) also causes some other 


More information about the En-Nut-Discussion mailing list