[Ace-users] [ace-users] [ace-bugs] ACE_Log_Msg: '%C' assumes wchar_t arg in ACE_USES_WCHAR builds

Douglas C. Schmidt schmidt at dre.vanderbilt.edu
Sat Mar 8 08:28:23 CST 2008


Hi Russell,

>    ACE VERSION: 5.4.8

Thanks for using the PRF.

>    HOST MACHINE and OPERATING SYSTEM:
>        If on Windows based OS's, which version of WINSOCK do you
>        use?:
>Windows
>
>    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>    COMPILER NAME AND VERSION (AND PATCHLEVEL):
>VS2008
>
>    THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
>    specific file, simply state which one]:
>Uses config-win32-msvc-8.h with ACE_USES_WCHAR defined
>
>    THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you
>    use a link to a platform-specific file, simply state which one
>    (unless this isn't used in this case, e.g., with Microsoft Visual
>    C++)]:
>
>    CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
>    (used by MPC when you generate your own makefiles):
>
>    AREA/CLASS/EXAMPLE AFFECTED:
>[What example failed?  What module failed to compile?]
>
>    DOES THE PROBLEM AFFECT:
>        COMPILATION?
>        LINKING?
>            On Unix systems, did you run make realclean first?
>        EXECUTION?
>Executation would be affected - this was noticed by code inspection
>
>        OTHER (please specify)?
>[Please indicate whether ACE, your application, or both are affected.]
>
>    SYNOPSIS:
>[Brief description of the problem]
>ACE_Log_Msg '%C' output format option assumes arg is a wchar_t string
>when ACE_USES_WCHAR is set.
>
>
>    DESCRIPTION:
>[Detailed description of problem.  Don't just say "<blah>
>doesn't work, here's a fix," explain what your program does
>to get to the <blah> state. ]
>ACE_Log_Msg supports a '%C' output format option which (supposedly)
>outputs a char string - it even uses the '%S' output format option on
>windows when ACE_USES_WCHAR is set, which causes wprintf and friends to
>output a char string
>(http://msdn2.microsoft.com/en-us/library/hf4y5e3w(VS.71).aspx).

Right, but we don't seem to be using wprintf(), right?  As a result, I
don't think 'C' is supposed to print a char rather than a WCHAR.  

>Whilst inspecting the code, however, I noticed that the arg is being
>cast to a ACE_TCHAR, which will be wchar_t when ACE_USES_WCHAR is set,
>rather than a char.  This seems wrong to me....
>
>    REPEAT BY:
>[What you did to get the error; include test program or session
>transcript if at all possible.  ]
>Code inspection.
>
>    SAMPLE FIX/WORKAROUND:
>[If available ]
>
>Change the
>   ACE_TCHAR *cstr =3D va_arg (argp, ACE_TCHAR *);
>
>To a:
>   char *cstr =3D va_arg (argp, char *);

I don't think this change is correct.  In fact, check out the
following comment:

                case 'C':         // Char string, Unicode for Win32/WCHAR

It looks to me like it's intending to use ACE_TCHAR here.

Thanks,

        Doug

-- 
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Vanderbilt University                        WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203                          NET: d.schmidt at vanderbilt.edu



More information about the Ace-users mailing list