I have issues with this patch.
Leopold Toetsch: # PIO_eprintf can fallback to vfprintf(3), when no # interpreter is supplied, which means that we should have compatible # format chars for basic data types.
First of all, spf_render.c:18-20: /* Per Dan's orders, we will not use sprintf if snprintf isn't * around for us. */
So we can't use vfprintf, unless Dan thinks otherwise.
Sorry, I don't get that. I see/know the point WRT sprintf, but all what we need is early on interpreter startup to be able to utter some (error) messages. These go straightly to stdout/stderr, that's it. No buffer involved. For this part of code - and for nothing else, its desirable, that you also can format INTVALs and much less FLOATVALs.
The problem here is that Windows uses a different flag for long ints--IIRC, they want you to use %I64d (no, I am not kidding). They don't seem to support long floats at all.
That's a oonfigure issue.
I chose the 'H' size for long floats *because* it would not overlap with
any system types, and I believe the correct solution is to somehow make
sure that Parrot_sprintf can be called with a NULL interpreter.
I don't think, that we need this. There is always an interpreter except during constructiing or destroying the first/last. For these 2 steps, we want a message stating a possible problem, thats it - IMHO.
Checking in several places for a valid interpreter - the whole call sequence up to memory allocation is something what I really don't like.
[2] Or not compile. I'm not sure which Parrot currently does for
systems with no snprintf.
I don't see a problem with vfprintf.
--Brent Dax <[EMAIL PROTECTED]>
leo
