Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1996 _MBCS mappings in tchar.h are missing

WSL
assigned
Earnie Boyd
TODO (3)
Support
later
WSL-5.0-feature
False
2013-07-15
2013-06-25
Earnie Boyd
No

This needs to be accomplished for the 5.0 version.

See include/mbctype.h for the TODO.

Related

Issues: #1995
Issues: #2000

Discussion

  • Keith Marshall
    Keith Marshall
    2013-06-25

    • summary: _MBSC mappings in tchar.h are missing --> _MBCS mappings in tchar.h are missing
     
  • Keith Marshall
    Keith Marshall
    2013-06-25

    Well, if you're going to include _tcsclen for 4.0, you at least need to make an early start; _tcsclen has three distinct mappings, dependent on _UNICODE, _MBCS, or neither. I'd suggest a section, at the end of, but within, the !_UNICODE block:

    :
    :
    #else /* ! _UNICODE */
    :
    :
    # ifdef _MBCS
    #  define _tcsclen  _mbslen
    
    # else /* ! _MBCS */
    #  define _tcsclen  strlen
    
    # endif /* ! _MBCS */
    #endif  /* ! _UNICODE */
    :
    

    Of course, within the preceding _UNICODE block, you also need:

    #define _tcsclen  wcslen
    
     
    • Earnie Boyd
      Earnie Boyd
      2013-06-25

      But which takes precedence in MS eyes? I'm thinking that _MBCS should take precedence over _UNICODE based on the table in the document reference.

       
      • Keith Marshall
        Keith Marshall
        2013-06-25

        But which takes precedence in MS eyes?

        I don't know. This is what I've challenged them to clarify.

        I'm thinking that _MBCS should take precedence over _UNICODE based on the table in the document reference.

        In the VS2012 reference, if you read the paragraph in which they identify the purpose of the _TCHAR data type, they imply that _UNICODE has precedence. Later, in the sequencing of the examples relating to _tcsrev, they imply the opposite.

        Logically, I think _UNICODE having precedence makes more sense. In reality, both being defined concurrently is anomalous, and would represent a programmer error; of course, programmers are human, and humans make such errors. Perhaps the sanest would be to give _UNICODE precedence, and #error in the _UNICODE block, if _MBCS is defined?

         
  • what do you think about this:

    #if defined(_UNICODE) & defined(_MBCS)
    #error undefined behavior _unicode , _mbcs
    #endif
    
    #if defined(UNICODE) & defined(_MBCS)
    #error undefined behavior unicode , _mbcs
    #endif
    
    #if defined(UNICODE) ^ defined(_UNICODE)
    #error Inconsitent unicode , _unicode definition
    #endif
    
     
    • Earnie Boyd
      Earnie Boyd
      2013-07-15

      Maybe; perhaps even before the file guard of _mingw.h. There is a problem with building ada-2.8.1 because of file inclusion ordering and the defining of UNICODE and _UNICODE. The TCHAR value was unicode specific while the function used with it was ANSI specific. Changing order of inclusion fixed the issue. For that we also need a filter checking the result of the __AW() macro compared to the UNICODE or _UNICODE defined value and that filter definitely would need to be before the file guard.

       
    • Keith Marshall
      Keith Marshall
      2013-07-15

      I had something like this in mind, although perhaps #warning rather than #error; somewhat less draconian, and any user preferring the #error can use -Werror to promote it.

      FTR, I can't find any explicit Microsoft expression of intent, but I did turn up a reference on CodeProject, or CodeGuru, or some such, suggesting that concurrent definition of _UNICODE and _MBCS results in undefined behaviour, (and UNICODE, without the underscore, isn't pertinent in the TCHAR context). Undefined behaviour doesn't necessarily demand a compiler abort, although of course, it doesn't rule it out.

       
      • Earnie Boyd
        Earnie Boyd
        2013-07-16

        Supposedly, _UNICODE is C runtime and UNICODE is Windows API. Of course that doesn't make too much sense given that using a unicode TCHAR variable gives a compiler error when using the Windows API with that variable. We can give a warning and let the compiler take care of the error.