I was just fiddling with some sine and cosine tables and needed some debugging.
But the output was always "0.00000". I tried to execute
float oneandahalf = 1.5f;
double twoandahalf = 2.5;
int one = 1;
char str[60];
sprintf(str, "1.5: %f 2.5: %f 1: %d", oneandahalf, twoandahalf, one);
show_msgbox(str, str);It compiles fine, result:

Dafuq is going on there
Same result with nspire_emu.

See if this works:

sprintf(str, "1.5: %f 2.5: %f 1: %d", 1.5, 2.5, 1);

It may at the very least narrow down the bug.

Nope, no change.

Code: [Select]

sprintf(str, "1: %d 2.5: %f 1.5: %f", 1, 2.5f, 1.5);prints: "1: 1 1.5: 0.000000 2.5: 0.000000".
Seems to be some kind of issue with va_list's and aligning, doesn't it?

Yeah... looks like something is wrong with sprintf itself or some type of alignment issue.

You should report the bug and give the examples that you posted here.

Maybe GCC and Nucleus / TI's code use different formats for floating-point values ?
(at least, TI's Lua and C do)

Tried that, doesn't work.
But it shouldn't confuse va_list.

sprintf(str, "%d, %f, %lf", 1, 1.5f, 2.5);Should be fine I think.

Maybe GCC and Nucleus / TI's code use different formats for floating-point values ?

Is sprintf a syscall? Isn't it included in newlib?

Edit:
Gcc thinks "1.5f" is a double..

sprintf is a syscall, yes. Ndless almost only uses syscalls and AFAIK doesn't use Newlib.

http://hackspire.unsads.com/wiki/index.php/C_and_assembly_development_introduction_on_Linux
But it gets build and gcc links against it.

Wouldn't it be better to provide it directly with newlib?
It would be faster and there will be no such problems anymore.
Only disadvantage would be the increasing size of the binary.

Edit: Workaround: Use http://stackoverflow.com/questions/2302969/how-to-implement-char-ftoafloat-num-without-sprintf-library-function-i.
The third answer works perfectly with floats, too.