[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Daniel Stutzbach added the comment: I opened a separate issue for the SIZEOF_WCHAR_T issue so I could refer to that issue number in Misc/NEWS. Fixed in r84317. -- status: open -> closed ___ Python tracker ___

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Changes by Daniel Stutzbach : -- dependencies: +PC/pyconfig.h should define SIZEOF_WCHAR_T ___ Python tracker ___ ___ Python-bugs-list

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Brian Curtin added the comment: +1 on option 1 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Daniel Stutzbach added the comment: On Windows, the Python headers define HAVE_USABLE_WCHAR_T and Py_UNICODE_SIZE 2, so we are already relying on sizeof(wchar_t) == 2 on Windows. My patch ran into trouble because it inadvertently disabled that assumption in a few places, causing code to take

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Marc-Andre Lemburg added the comment: Daniel Stutzbach wrote: > > Daniel Stutzbach added the comment: > > The underlying problem here is that SIZEOF_WCHAR_T is not defined in > pyconfig.h on Windows. My patch assumed that it would be defined on all > platforms where HAVE_WCHAR_H is defined

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Daniel Stutzbach added the comment: Adding other Windows developers to the nosy list. See msg114893 where your input would be helpful. -- nosy: +brian.curtin, tim.golden ___ Python tracker ___

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Daniel Stutzbach added the comment: The underlying problem here is that SIZEOF_WCHAR_T is not defined in pyconfig.h on Windows. My patch assumed that it would be defined on all platforms where HAVE_WCHAR_H is defined (I had checked ./configure, but forgotten Windows). This has come up before

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Daniel Stutzbach added the comment: Thanks, I will take a look sometime today. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Florent Xicluna added the comment: Hi Daniel, there's a test failure which is related with r84307 on windows buildbot. == FAIL: test_cw_strings (ctypes.test.test_parameters.SimpleTypesTestCase)

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Daniel Stutzbach added the comment: Commited in r84307. -- keywords: -needs review resolution: -> accepted stage: patch review -> committed/rejected status: open -> closed ___ Python tracker _

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Marc-Andre Lemburg added the comment: Daniel Stutzbach wrote: > > Daniel Stutzbach added the comment: > > Thanks. I dug into that a little just now, and it turns out to happen > automatically. > > If ./configure doesn't define HAVE_WCHAR_H then it also will not define > SIZEOF_WCHAR_T. I

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Daniel Stutzbach added the comment: Thanks. I dug into that a little just now, and it turns out to happen automatically. If ./configure doesn't define HAVE_WCHAR_H then it also will not define SIZEOF_WCHAR_T. If SIZEOF_WCHAR_T is not defined, the preprocessor will treat it as 0 causing it

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Marc-Andre Lemburg added the comment: Daniel Stutzbach wrote: > > Daniel Stutzbach added the comment: > > Attached is a patch implementing the change agreed upon in the earlier > discussion. This will allow wchar_t <-> Py_UNICODE conversions to use memcpy > on systems where wchar_t and Py_

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Daniel Stutzbach added the comment: Attached is a patch implementing the change agreed upon in the earlier discussion. This will allow wchar_t <-> Py_UNICODE conversions to use memcpy on systems where wchar_t and Py_UNICODE have the same size but different signs (e.g., Linux). -- ke

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > The problem with a signed Py_UNICODE is implicit sign extension (rather than > zero extension) in some conversions, for example from "char" or "unsigned > char" to "Py_UNICODE". The effects

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Daniel Stutzbach added the comment: Yeah, this is a "I noticed this small optimization while working on something else" kind of thing. ;) ("something else" being Issue8654) I can make a patch to change the #if's to test Py_UNICODE_SIZE == SIZEOF_WCHAR_T, though I'll give others a few days to

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Antoine Pitrou added the comment: > Another option would be to test Py_UNICODE_SIZE == SIZEOF_WCHAR_T to > enable the optimizations, instead of defined(HAVE_USABLE_WCHAR_T). > The plus side is that we wouldn't be changing the semantics of > anything. I guess it's sufficient, indeed. Besides, th

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Daniel Stutzbach added the comment: Usually you wouldn't want to cast a char directly to a Py_UNICODE, because you need to take into account the encoding of the char and map it to the appropriate Unicode character. The exception is when you're certain the char is 7-bit ASCII, which is a subs

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

Antoine Pitrou added the comment: The problem with a signed Py_UNICODE is implicit sign extension (rather than zero extension) in some conversions, for example from "char" or "unsigned char" to "Py_UNICODE". The effects could go anywhere from incorrect results to plain crashes. Not only in ou

[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)

New submission from Daniel Stutzbach : If ./configure detects that the system's wchar_t type is compatible, it will define "#define PY_UNICODE_TYPE wchar_t" and enable certain optimizations when converting between Py_UNICODE and wchar_t (i.e., it can just do a memcpy). Right now, ./configure c