+#if wxUSE_UNICODE_UTF8
+int wxString::DoPrintfUtf8(const char *format, ...)
+{
+ va_list argptr;
+ va_start(argptr, format);
+
+ int iLen = PrintfV(format, argptr);
+
+ va_end(argptr);
+
+ return iLen;
+}
+#endif // wxUSE_UNICODE_UTF8
+
+/*
+ Uses wxVsnprintf and places the result into the this string.
+
+ In ANSI build, wxVsnprintf is effectively vsnprintf but in Unicode build
+ it is vswprintf. Due to a discrepancy between vsnprintf and vswprintf in
+ the ISO C99 (and thus SUSv3) standard the return value for the case of
+ an undersized buffer is inconsistent. For conforming vsnprintf
+ implementations the function must return the number of characters that
+ would have been printed had the buffer been large enough. For conforming
+ vswprintf implementations the function must return a negative number
+ and set errno.
+
+ What vswprintf sets errno to is undefined but Darwin seems to set it to
+ EOVERFLOW. The only expected errno are EILSEQ and EINVAL. Both of
+ those are defined in the standard and backed up by several conformance
+ statements. Note that ENOMEM mentioned in the manual page does not
+ apply to swprintf, only wprintf and fwprintf.
+
+ Official manual page:
+ http://www.opengroup.org/onlinepubs/009695399/functions/swprintf.html
+
+ Some conformance statements (AIX, Solaris):
+ http://www.opengroup.org/csq/view.mhtml?RID=ibm%2FSD1%2F3
+ http://www.theopengroup.org/csq/view.mhtml?norationale=1&noreferences=1&RID=Fujitsu%2FSE2%2F10
+
+ Since EILSEQ and EINVAL are rather common but EOVERFLOW is not and since
+ EILSEQ and EINVAL are specifically defined to mean the error is other than
+ an undersized buffer and no other errno are defined we treat those two
+ as meaning hard errors and everything else gets the old behaviour which
+ is to keep looping and increasing buffer size until the function succeeds.
+
+ In practice it's impossible to determine before compilation which behaviour
+ may be used. The vswprintf function may have vsnprintf-like behaviour or
+ vice-versa. Behaviour detected on one release can theoretically change
+ with an updated release. Not to mention that configure testing for it
+ would require the test to be run on the host system, not the build system
+ which makes cross compilation difficult. Therefore, we make no assumptions
+ about behaviour and try our best to handle every known case, including the
+ case where wxVsnprintf returns a negative number and fails to set errno.
+
+ There is yet one more non-standard implementation and that is our own.
+ Fortunately, that can be detected at compile-time.
+
+ On top of all that, ISO C99 explicitly defines snprintf to write a null
+ character to the last position of the specified buffer. That would be at
+ at the given buffer size minus 1. It is supposed to do this even if it
+ turns out that the buffer is sized too small.
+
+ Darwin (tested on 10.5) follows the C99 behaviour exactly.
+
+ Glibc 2.6 almost follows the C99 behaviour except vswprintf never sets
+ errno even when it fails. However, it only seems to ever fail due
+ to an undersized buffer.
+*/
+#if wxUSE_UNICODE_UTF8
+template<typename BufferType>
+#else
+// we only need one version in non-UTF8 builds and at least two Windows
+// compilers have problems with this function template, so use just one
+// normal function here
+#endif
+static int DoStringPrintfV(wxString& str,
+ const wxString& format, va_list argptr)
projects / wxWidgets.git / blobdiff