Re: riched20: EM_GETLINE implementation and test
On 6/22/06, Krzysztof Foltman <wdev(a)foltman.com> wrote:
This patch seems to have been overlooked or rejected - yet I do not see any reason being mentioned.
Was it rejected because of use of L"" syntax?
Probably, L"" is not portable, and you have to use: static const WHCAR string[] = {'s','t','r','i','n','g',0}; -- James Hawkins
James Hawkins wrote:
Probably, L"" is not portable, and you have to use:
static const WHCAR string[] = {'s','t','r','i','n','g',0};
I'm just curious: not arguing, ;) but Plauger says, in "The Standard C Library" (1992, p. 219): "You write a wide character constant as, for example, L'x'. It has type wchar_t. You write a wide characer string literal as, for example, L"hello". It has type array of wchar_t. wchar_t is an integer type that can represent all the code values for all wide-character encodings supported by the implementation." Why might it not be portable? -- Andy.
On 6/22/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote:
James Hawkins wrote:
Probably, L"" is not portable, and you have to use:
static const WHCAR string[] = {'s','t','r','i','n','g',0};
I'm just curious: not arguing, ;) but Plauger says, in "The Standard C Library" (1992, p. 219): "You write a wide character constant as, for example, L'x'. It has type wchar_t. You write a wide characer string literal as, for example, L"hello". It has type array of wchar_t. wchar_t is an integer type that can represent all the code values for all wide-character encodings supported by the implementation." Why might it not be portable?
To be as portable as possible, we code to the lowest common denominator. Not all compilers support L"". We adhere to C89, but I can't remember what it says about L"", if anything. The point is that WCHAR blah[] ={...} will work for every compiler. -- James Hawkins
"James Hawkins" <truiken(a)gmail.com> writes in gmane.comp.emulators.wine.devel:
On 6/22/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote:
James Hawkins wrote:
Probably, L"" is not portable, and you have to use:
static const WHCAR string[] = {'s','t','r','i','n','g',0};
I'm just curious: not arguing, ;) but Plauger says, in "The Standard C Library" (1992, p. 219): "You write a wide character constant as, for example, L'x'. It has type wchar_t. You write a wide characer string literal as, for example, L"hello". It has type array of wchar_t. wchar_t is an integer type that can represent all the code values for all wide-character encodings supported by the implementation." Why might it not be portable?
To be as portable as possible, we code to the lowest common denominator. Not all compilers support L"". We adhere to C89, but I can't remember what it says about L"", if anything. The point is that WCHAR blah[] ={...} will work for every compiler.
Well, perhaps you then need also special options if you use L"..." man gcc: -fshort-wchar Override the underlying type for wchar_t to be short unsigned int instead of the default for the target. This option is useful for building programs to run under WINE. / Kari Hurtta
James Hawkins wrote:
To be as portable as possible, we code to the lowest common denominator. Not all compilers support L"". We adhere to C89, but I can't remember what it says about L"", if anything. The point is that WCHAR blah[] ={...} will work for every compiler.
From what I can tell, L"" is good in C89 (although the result of concatenating a wide string and a narrow string is undefined). However, the width of wchar_t is implementation-dependent, and may have a width anywhere between that of char and unsigned long (though, in practice, it is likely to be a synonym for an integer type that has at least a 16-bit representation, such as short or unsigned short). Whereas WCHAR is set to have a width of sixteen bits. So I think this is why the L-prefix form is not portable.
Thanks for helping me down this road of discovery. -- Andy.
James Hawkins wrote:
To be as portable as possible, we code to the lowest common denominator. Not all compilers support L"". We adhere to C89, but I can't remember what it says about L"", if anything. The point is that WCHAR blah[] ={...} will work for every compiler.
wchar_t is an int on some versions of gcc. It can be made a short using -fshort-wchar, but only later versions of gcc (3.0+) support that flag. Mike
On Thu, Jun 22, 2006 at 10:36:10PM +0100, Andrew Talbot wrote:
James Hawkins wrote:
Probably, L"" is not portable, and you have to use:
static const WHCAR string[] = {'s','t','r','i','n','g',0};
I'm just curious: not arguing, ;) but Plauger says, in "The Standard C Library" (1992, p. 219): "You write a wide character constant as, for example, L'x'. It has type wchar_t. You write a wide characer string literal as, for example, L"hello". It has type array of wchar_t. wchar_t is an integer type that can represent all the code values for all wide-character encodings supported by the implementation." Why might it not be portable?
In Linux, L"" makes 4 byte character strings (if not using explicit -fshort-wchar). Also, if the user then calls wc* functions from glibc, they will use 4 byte characters. It is all to avoid confusion. Ciao, Marcus
Marcus Meissner wrote:
In Linux, L"" makes 4 byte character strings (if not using explicit -fshort-wchar). Also, if the user then calls wc* functions from glibc, they will use 4 byte characters.
It is all to avoid confusion.
Ciao, Marcus
Interestingly, it looks like, in one standard version of C, at least - maybe not C89 - there is now a pair of utf16 string-literal constructs: u'x' an u"string". But that's another story. Thanks, Marcus (and Mike)! -- Andy.
participants (5)
-
Andrew Talbot -
James Hawkins -
Kari Hurtta -
Marcus Meissner -
Mike McCormack