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:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, if you're going to include
_tcsclenfor 4.0, you at least need to make an early start;_tcsclenhas three distinct mappings, dependent on_UNICODE,_MBCS, or neither. I'd suggest a section, at the end of, but within, the!_UNICODEblock:Of course, within the preceding
_UNICODEblock, you also need: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.
I don't know. This is what I've challenged them to clarify.
In the
VS2012reference, if you read the paragraph in which they identify the purpose of the_TCHARdata type, they imply that_UNICODEhas precedence. Later, in the sequencing of the examples relating to_tcsrev, they imply the opposite.Logically, I think
_UNICODEhaving 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_UNICODEprecedence, and#errorin the_UNICODEblock, if_MBCSis defined?what do you think about this:
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.
I had something like this in mind, although perhaps
#warningrather than#error; somewhat less draconian, and any user preferring the#errorcan use-Werrorto 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
_UNICODEand_MBCSresults in undefined behaviour, (andUNICODE, without the underscore, isn't pertinent in theTCHARcontext). Undefined behaviour doesn't necessarily demand a compiler abort, although of course, it doesn't rule it out.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.