While going through the file wchar.h on Mac OS X system, I found that wchar_t equivalent of str functions such as wcscpy, wcscat are poisoned when __cplusplust is not defined and max size of wchar_t is of 2 bytes (by using compiler option -fshort-wchar).
It seems that for C program, it does not allow such functions to use if -fshort-wchar is defined. I would like to know that what is the implication of using wchar_t functions when -fshort-wchar is used?
You may wonder that why I need to use -fshort-wchar. Because, I am porting an application initially written for Windows where size of wchar_t is two bytes. And that data held in wchar_t string is written on the file and also exchanged between two applications.
What is a good way to handle the variability of wchar_t on different platforms? Assumption on Windows is that wchar_t is of 16 bits.
-fshort-wchar
is not usable if you want to interact with any part of the standard library or third-party library code using the correct (32-bit) definition of wchar_t
. The situations where it's viable are very limited and probably pertain mostly to freestanding-implementation/embedded stuff.
In the case of porting the Windows application you're dealing with, I think you should just do a seatch-and-replace to change these uses of wchar_t
to WCHAR
(which you're free to define) or char16_t
(defined by C11, and you can supply your own definition pre-C11).
If we go with typedef uint16_t Char;
What about String literals in the code? and the problem third party remain the same. These have to converted to wchar_t(UTF-32_ before passing.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With