Leopold Toetsch: # Brent Dax wrote: # > 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.
You're right about this, of course. Sorry, I wasn't thinking it through completely. *smacks forehead on table* # > 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. It becomes an sprintf issue when people start passing things with platform-specific flags in them to the platform-neutral Parrot_sprintf--and if you allow INTVAL_FMT to be used directly on some systems, someone'll use it, and it'll bite us on Windows. # > 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. *nod* Okay. To restate, though, I still don't like supporting %Ld in Parrot_sprintf, because someone'll (probably accidentally) pass in %I64d on a Windows system or God-knows-what-syntax on some other strange system, and I don't want to have to support *that*. --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."
