Am 05.10.2011 15:30, schrieb Donald G Porter:
> Joe English wrote:>> Note that the representation of a 'va_list' is not usually>> specified in the C ABI for most architectures, so Tcl_*VA()>> routines are contraindicated in Stubs-enabled extensions.>>>> In particular, MSVC and GCC 'va_list's are not compatible.>>>> Variadic functions are OK, it's only when you call 'va_start()'>> in code compiled by one compiler and 'va_arg()' in code compiled>> by another that the problem shows up.>>>> (IIRC, this is why the *VA() variants weren't added to the Stubs>> table in the first place.)>> Hmmm... So from that perspective, perhaps the presence of Tcl_PanicVA()> in the stubs table is a mistake we'd be better off not repeating?>> Roman Puls, can you say more about why you want Tcl_ObjPrintfVA()> made available? Do you plan to call it through the stubs table?>
Sure, I can. I am writing c-extensions for Tcl, and Tcl_ObjPrintfVA (or
similiar) is needed* when the current function already receives an
variable argument list.
I am usually linking against a specific tcl lib, and wouldn't need the
stub to work.
Cheers,
Roman
*of course, i can do snprintf, measure the length, allocate memory,
re-run snprintf and then create a new Tcl_Obj, but everything is in
place, but simply has no interface.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core