Solved: IUtility->SNPrintf "bug"<=misunderstanding

This function call:
char str[50+1];
IUtility->SNPrintf(str,sizeof(str),"%d%d%d%d%d%d",1,2,3,4,5,6);

causes this output:
010203

utility.library 53.1 (16.6.08)

I hope it will be fixed (if it's not already).

@TSK

That's not a bug, as you'll find if you read the documentation. SNPrintf() does not behave the same as the printf()" in the C run-time libraries clib or newlib.

AmigaOS always puts 32-bit data on the stack, so "%d" will put a 32-bit uint32 on the stack. In the low-level functions like IExec->#? and IUtility->#?, you have to use the formatting codes "%ld", "%lx%, etc.

So your example should be changed to read:
IUtility->SNPrintf(str,sizeof(str),"%ld%ld%ld%ld%ld%ld",1,2,3,4,5,6);
...then it will give the right values.

For instance, if you want to print a single byte as a hex character, you must use "0x%02lx" to get say "0x41" for an "A".

Note also that SNPrintf returns a character count that INCLUDES the null on the end of the string (unlike the C run-time library printf()).

@tonyw

Thanks ! There's %ld used in the example but not mentioned anywhere that it's mandatory.

@TSK

This is mentioned in the documentation for RawDoFmt() which is used by (almost) every Amiga API function needing to format a character stream. So you will meet the same requirements for PrintF() & friends, SNPrintF() & friends, requesters, Reaction classes format strings using varargs...

An exception to this is DebugPrintF() (and possibly the only one).

@centaurz

My bad. Autodocs tells to check also RawDoFmt() but I didn't do it because I remembered from classic era (1990's) that RawDoFmt() was like C string formatting functions. Funny I didn't notice anything using IDOS->Printf(). Warning text of RawDoFmt() tells it's depended on compiler if it uses words or longs by default.

@centaurz

You have to use the same strange formatting with IExec->DebugPrintF() as well. Even more, if you have some int64s that you want to print, you have to pad the int32s out to int64 if you mix them, since int64s are lined up on 8-byte boundaries.

For example, DebugPrintF ("%lld, %ld\n", int64, int32) works OK, but
DebugPrintF (%ld, %lld\n", int32, int64) will give the wrong result for the int64, you have to say DebugPrintF ("%ld, %lld\n", int32, dummy int32, int64).

@tonyw

I've never had trouble using e.g. "%d" to output integers with DebugPrintF(), the documentation does not refer to RawDoFmt-style formatting but standard printf one.
Regarding the alignment issue with int64, it may be a limitation of the linear varargs versus standard ABI.

@centaurz

[Just trying it]

Yes, you're right. I don't remember where I got that idea from, but I've always used DebugPrintF that way, so I've been doing it like that for years!

Alignment seems to be a problem only with 64-bit data.