[issue9036] Simplify Py_CHARMASK

Stefan Krah added the comment: Antoine, Eric, thanks for looking at the patch. unicodeobject.c patch committed in r82978, r82979, r82980 and r82984. As Antoine pointed out, the _json.c issue is not a problem. Also, it is not present in py3k. The reliable buildbots look ok, so I think we can clo

[issue9036] Simplify Py_CHARMASK

Eric Smith added the comment: Yes, the unicode patch looks okay to me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue9036] Simplify Py_CHARMASK

Antoine Pitrou added the comment: Eric, is the unicode patch ok for you? -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue9036] Simplify Py_CHARMASK

Stefan Krah added the comment: Antoine, thanks! Committed in r82966, r82968, r82969 and r82970. Could we fix the unicodeobject.c bug on the fly? I think the patch should do, unless non-ascii digits are supported. But in that case several other changes would be needed. -- Added file: h

[issue9036] Simplify Py_CHARMASK

Antoine Pitrou added the comment: > Antoine, I understood that you would prefer to leave the mask. Could I > apply the second version of the patch? It looks ok to me. -- ___ Python tracker

[issue9036] Simplify Py_CHARMASK

Stefan Krah added the comment: [Marc-Andre] > Why not just make the casts in those cases explicit instead of > using Py_CHARMASK ? I agree that this would be the cleanest solution. It's harder to get someone to review a larger patch though. Antoine, I understood that you would prefer to leave

[issue9036] Simplify Py_CHARMASK

Antoine Pitrou added the comment: > Ok, let's say we use ((unsigned char)((c) & 0xff)) also for > __CHAR_UNSIGNED__. > > What should the comment say about the intended argument? That it's either in [-128; 127] or in [0; 255] ? > Index: Objects/unicodeobject.c > ===

[issue9036] Simplify Py_CHARMASK

Marc-Andre Lemburg added the comment: Stefan Krah wrote: > > Stefan Krah added the comment: > > Antoine Pitrou wrote: >>> Thus, >>> ((unsigned char)((c) & 0xff)) and ((unsigned char)(c)) should produce >>> the same results. >> >> If it's the case, it's probably optimized away by the compiler

[issue9036] Simplify Py_CHARMASK

Stefan Krah added the comment: > In r61936 the cast was added. Actually r61987 -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue9036] Simplify Py_CHARMASK

Stefan Krah added the comment: Antoine Pitrou wrote: > > Thus, > > ((unsigned char)((c) & 0xff)) and ((unsigned char)(c)) should produce > > the same results. > > If it's the case, it's probably optimized away by the compiler anyway. Yes, the asm output is the same. I was more concerned about

[issue9036] Simplify Py_CHARMASK

Antoine Pitrou added the comment: > Thus, > ((unsigned char)((c) & 0xff)) and ((unsigned char)(c)) should produce > the same results. If it's the case, it's probably optimized away by the compiler anyway. > There is no reason not to do the cast when __CHAR_UNSIGNED__ is > defined (it will be a

[issue9036] Simplify Py_CHARMASK

New submission from Stefan Krah : This feature request is extracted from issue 9020, where Py_CHARMASK(c) was used on EOF, producing different results depending on whether __CHAR_UNSIGNED__ is defined or not. The preferred fix for issue 9020 is to check for EOF before using Py_CHARMASK, so this