[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)

STINNER Victor added the comment: The changeset a7a8ccf69708 (a few months ago) fixed lib_python to not concatenate bytes string and wide character string. I don't see any occurence of char+wchar in the code, so I'm closing the issue. changeset: 87136:a7a8ccf69708 user:Victor Stinner

[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)

Jim Jewett added the comment: Following up on Mark Lawrence's comment: http://bugs.python.org/issue12572 is collecting the patches required to compile under HP/UX, and the patch there supersedes those on this issue. Closing. -- nosy: +Jim.Jewett resolution: -> duplicate status: open

[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)

Mark Lawrence added the comment: According to msg140433 this should be closed. -- nosy: +BreamoreBoy ___ Python tracker ___ ___ Python

[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)

Jim Schneider added the comment: Constant initializers are required to be constants, not function calls, so _Py_char2wchar cannot be used in the definition of lib_python (line #138 of Modules/getpath.c). -- ___ Python tracker

[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)

STINNER Victor added the comment: > Stinner - is the patch you mentioned in a released version > of Python 3.2? Yes, Python 3.2.1. (It's not part of Python 3.1.) > Also, how is it affected by the fact that the (wide char) strings > in question are constants? I don't remember exactly. My patch

[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)

Jim Schneider added the comment: I am collecting HP/UX compiler bug workarounds in issue 12572. Stinner - is the patch you mentioned in a released version of Python 3.2? Also, how is it affected by the fact that the (wide char) strings in question are constants? --

[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)

STINNER Victor added the comment: Use >L"" CONSTANT< to decode a byte string to a character string doesn't work with non-ASCII strings. _Py_char2wchar() should be used instead: see for example this fix, commit 5b6e13b6b473. -- nosy: +haypo ___ Pyth

[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)

Jim Schneider added the comment: I am attaching an updated patch. This version specifically checks for __hpux, and the macro name has been changed to avoid clashing with other uses. -- Added file: http://bugs.python.org/file22663/getpath.patch ___

[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)

Jim Schneider added the comment: The __W macro is needed because the token-pasting operator binds to the macro's argument immediately; Having WCHAR(y) expand to __W(y) means that __W is passed WCHAR's argument after it's been macro-expanded. Without the intermediate step, WCHAR(VERSION) bec

[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)

Martin v. Löwis added the comment: Why is the __W macro needed? Please don't call it WCHAR: - it conflicts with a same-named macro on Windows - you are applying it to strings, not characters FWIW, the compiler doesn't conform to standard C if it rejects this code. 6.4.5p4 says [#4]

[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)

New submission from Jim Schneider : In Modules/getpath.c, the following line (#138) causes problems with some compilers (HP/UX 11, in particular - there could be others): static wchar_t *lib_python = L"lib/python" VERSION; Similarly, line #644: module_search_path = L"" PYTHONPATH; Th