OS X 上的 vwprintf/vswprintf 出现问题

发布于 2024-12-21 08:46:26 字数 1666 浏览 1 评论 0原文

为了提供更多细节,我正在使用 XCode 4.2 和 LLVM GCC 4.2.2 编译器使用 C for OS X 编写代码。

我有一个可变参数函数 - 为了完整性,我包含了整个函数,尽管我/相信/其中大部分是无关紧要的,我遇到的唯一问题是 vswprintf 在某些情况下的行为方式。

void FTFRenderText( const struct FTFFont* const pxFont,
               const int iStartX, const int iStartY,
               const wchar_t* const wszFormatString,
               ... )
{
    if( !pxFont || !( pxFont->mbValid ) )
    {
        return;
    }

    static wchar_t lswszBuffer[ 2048 ];    
    va_list xArguments;
    va_start( xArguments, wszFormatString );
    //
    // SE - TODO: remove
    vwprintf( wszFormatString, xArguments );
    va_end( xArguments );
    va_start( xArguments, wszFormatString );
    //
    vswprintf( lswszBuffer, 2048, wszFormatString, xArguments );
    va_end( xArguments );
    const struct FTFTriList xTriList =
        FTFCreateTriListFromText( pxFont, iStartX, iStartY, lswszBuffer );

    const int iIndexCount = xTriList.miNumIndices;
    if( iIndexCount )
    {
        // SE - TODO: something to allow user selected colour
        glColor4f( 1.0f, 1.0f, 1.0f, 1.0f );
        glVertexPointer( 2, GL_FLOAT, 0, xTriList.mpfVertices );
        glDrawElements(
            GL_TRIANGLES, iIndexCount, GL_UNSIGNED_SHORT, xTriList.mpsIndices );
    }
}

也许我很昏暗,但似乎如果我传递一组足够简单的参数,如“Test %d”,101,函数就可以正常工作。但是,如果我传入一个带有 unicode 字符的字符串,无论是作为文字还是使用 \uXXXX,我从 vswprintf 返回的字符串完全是空的在调试器中,我可以看到编译器已经对内存中的字符串做了正确的操作,它包含 unicode 字符 - 但 vswprintf 写入的字符串全是 0。

与 wprintf 和 vwprintf 进行比较很有趣 - 因为两者似乎都按照我的预期运行,并从文字和 \uXXXX 转义中生成预期的 unicode 字符。

我不愿意说这个库有问题,因为很多其他库和应用程序都构建在上面,所以我认为我做错了什么,但我只是看不出它可能是什么......

任何建议或帮助将不胜感激。

To give more detail I am writing the code using C for OS X using XCode 4.2 and the LLVM GCC 4.2.2 compiler.

I have a variable argument function - I include the entire function for completeness although I /believe/ most of it to be irrelevant, the only problem I have is with how vswprintf behaves in some cases.

void FTFRenderText( const struct FTFFont* const pxFont,
               const int iStartX, const int iStartY,
               const wchar_t* const wszFormatString,
               ... )
{
    if( !pxFont || !( pxFont->mbValid ) )
    {
        return;
    }

    static wchar_t lswszBuffer[ 2048 ];    
    va_list xArguments;
    va_start( xArguments, wszFormatString );
    //
    // SE - TODO: remove
    vwprintf( wszFormatString, xArguments );
    va_end( xArguments );
    va_start( xArguments, wszFormatString );
    //
    vswprintf( lswszBuffer, 2048, wszFormatString, xArguments );
    va_end( xArguments );
    const struct FTFTriList xTriList =
        FTFCreateTriListFromText( pxFont, iStartX, iStartY, lswszBuffer );

    const int iIndexCount = xTriList.miNumIndices;
    if( iIndexCount )
    {
        // SE - TODO: something to allow user selected colour
        glColor4f( 1.0f, 1.0f, 1.0f, 1.0f );
        glVertexPointer( 2, GL_FLOAT, 0, xTriList.mpfVertices );
        glDrawElements(
            GL_TRIANGLES, iIndexCount, GL_UNSIGNED_SHORT, xTriList.mpsIndices );
    }
}

Perhaps I am being dim but it seems that if I pass in a simple enough set of parameters like "Test %d", 101 the functions work fine. However if I pass in a string with a unicode character, either as a literal or using \uXXXX the string I get back from vswprintf is completely empty In the debugger I can see the the compiler has done the right thing with the string in memory, and it contains the unicode character - but the string written to by vswprintf is all 0s.

Comparing with wprintf and vwprintf is interesting - because both seem to behave as I expect and produce the expected unicode character from both a literal and the \uXXXX escaping.

I am loathe to suggest the library is buggy because a great number of other libraries and apps have been built on top just fine, so I think I am doing something wrong, but I just can't see what it could possibly be...

Any suggestions or help would be greatly appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

裂开嘴轻声笑有多痛 2024-12-28 08:46:26

从来没有答案,所以让我至少提供一个可能的最草率的答案:

使用 UTF-8。

OS X/iOS 中的所有 ansi 字符串函数实际上都是伪装的 utf-8 函数。

There was never answer, so let me at least provide the sloppiest one possible:

Use UTF-8.

All of the ansi string functions in OS X/iOS are actually utf-8 functions in disguise.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文