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.
# The attached patch seems to cure the problem. pdb is working then. But
# the patch isn't complete. I think, we should also have support for
# "%lld" and friends.
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.
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
honestly can't remember if it can, and the source doesn't clearly
indicate either way, but I think at some point I was trying to do so.
If nothing else, we might be able to get away with parsing the format
string, then deparsing it back into something appropriate for the
system[1]; if we do this, we'll have to panic if snprintf isn't
available[2].
(Sorry for the sketchiness. I recently reinstalled Windows, so my
toolkit isn't in place yet, and I wasn't able to beat enough info out of
cvsweb to know for sure.)
[1] We already have this partially implemented. Parrot_sprintf falls
back to the system's vsnprintf when there are floats involved, basically
because I didn't and probably still don't have the tuits to write that
sort of float handling. The call to snprintf is on spf_render.c:585.
[2] Or not compile. I'm not sure which Parrot currently does for
systems with no snprintf.
--Brent Dax <[EMAIL PROTECTED]>
Perl and Parrot hacker
"Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it."
