Re: [Python-Dev] ssize_t branch merged
Neal Norwitz wrote: I suppose that might be nice, but would require configure magic. I'm not sure how it could be done on Windows. Contributions are welcome. On Windows, it can be hard-coded. Actually, something like #if SIZEOF_SIZE_T == SIZEOF_INT #define PY_SSIZE_T_MAX INT_MAX #elif SIZEOF_SIZE_T == SIZEOF_LONG #define PY_SSIZE_T_MAX LONG_MAX #else #error What is size_t equal to? #endif might work. There are much more important problems to address at this point IMO. Just review the recent fixes related to Py_BuildValue() on python-checkins to see what I mean. Nevertheless, it would be desirable IMO if it expanded to a literal, so that the preprocessor could understand it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssize_t branch merged
Martin v. Löwis wrote: Neal Norwitz wrote: I suppose that might be nice, but would require configure magic. I'm not sure how it could be done on Windows. Contributions are welcome. On Windows, it can be hard-coded. Actually, something like #if SIZEOF_SIZE_T == SIZEOF_INT #define PY_SSIZE_T_MAX INT_MAX #elif SIZEOF_SIZE_T == SIZEOF_LONG #define PY_SSIZE_T_MAX LONG_MAX #else #error What is size_t equal to? #endif might work. Why not just #if SIZEOF_SIZE_T == 2 #define PY_SSIZE_T_MAX 0x7fff #elif SIZEOF_SIZE_T == 4 #define PY_SSIZE_T_MAX 0x7fff #elif SIZEOF_SIZE_T == 8 #define PY_SSIZE_T_MAX 0x7fff #elif SIZEOF_SIZE_T == 16 #define PY_SSIZE_T_MAX 0x7fff #endif ? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssize_t branch merged
Travis E. Oliphant wrote: Why not just #if SIZEOF_SIZE_T == 2 #define PY_SSIZE_T_MAX 0x7fff #elif SIZEOF_SIZE_T == 4 #define PY_SSIZE_T_MAX 0x7fff #elif SIZEOF_SIZE_T == 8 #define PY_SSIZE_T_MAX 0x7fff #elif SIZEOF_SIZE_T == 16 #define PY_SSIZE_T_MAX 0x7fff #endif That would not work: 0x7fff is not a valid integer literal. 0x7fffL might work, or 0x7fffLL, or 0x7fffi64. Which of these is correct depends on the compiler. How to spell 128-bit integral constants, I don't know; it appears that MS foresees a i128 suffix for them. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssize_t branch merged
Martin v. Löwis wrote: Just in case you haven't noticed, I just merged the ssize_t branch (PEP 353). If you have any corrections to the code to make which you would consider bug fixes, just go ahead. If you are uncertain how specific problems should be resolved, feel free to ask. If you think certain API changes should be made, please discuss them here - they would need to be reflected in the PEP as well. What is PY_SSIZE_T_MAX supposed to be? The definition in pyport.h doesn't compile. Shouldn't a lot of checks for INT_MAX be replaced with PY_SSIZE_T_MAX? Like in the slice indexing code? Thanks for all your effort on ssize_t fixing. This is a *big* deal for 64-bit number crunching with Python. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssize_t branch merged
On Fri, Feb 17, 2006 at 04:40:08PM -0700, Travis Oliphant wrote: What is PY_SSIZE_T_MAX supposed to be? The definition in pyport.h doesn't compile. Why not? Does it give an error for your particular platform? What platform is that? What are HAVE_SSIZE_T, SIZEOF_VOID_P and SIZEOF_SIZE_T defined to be? While looking at the piece of code in Include/pyport.h I do notice that the fallback (when ssize_t is not available) is to Py_uintptr_t... Which is an unsigned type, while ssize_t is supposed to be signed. Martin, is that on purpose? I don't have any systems that lack ssize_t. ;P That should prevent the PY_SSIZE_T_MAX definition from compiling though. Shouldn't a lot of checks for INT_MAX be replaced with PY_SSIZE_T_MAX? Like in the slice indexing code? Yes, ideally. (Actually, I think slice indexing was changed earlier today.) But while changing it would have little to no effect on 32-bit machines, doing it the wrong way may break the code on 64-bit machines in subtle ways, so it's not all done blindly, or in one big shot. Also, because some output parameters to PyArg_ParsE* change size (s#/t#), code will have to be reviewed to make use of the full address range anyway. (There's some preprocessor hackery that checks for PY_SIZE_T_CLEAN to see if it's safe to use the large output versions.) Adapting all code in the right way isn't finished yet (not in the last place because some of the code is... how shall I put it... 'creative'.) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssize_t branch merged
Thomas Wouters wrote: On Fri, Feb 17, 2006 at 04:40:08PM -0700, Travis Oliphant wrote: What is PY_SSIZE_T_MAX supposed to be? The definition in pyport.h doesn't compile. Maybe I have the wrong version of code. In my pyport.h (checked out from svn trunk) I have. #define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)1)) What is size_t? Is this supposed to be sizeof(size_t)? I get a syntax error when I actually use PY_SSIZE_T_MAX somewhere in the code. While looking at the piece of code in Include/pyport.h I do notice that the fallback (when ssize_t is not available) is to Py_uintptr_t... Which is an unsigned type, while ssize_t is supposed to be signed. Martin, is that on purpose? I don't have any systems that lack ssize_t. ;P I saw the same thing and figured it was an error. Adapting all code in the right way isn't finished yet (not in the last place because some of the code is... how shall I put it... 'creative'.) I'm just trying to adapt my __index__ patch to use ssize_t. I realize this was a big change and will take some adjusting. I can help with that if needed as I do have some experience here. I just want to make sure I fully understand what issues Martin and others are concerned about. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssize_t branch merged
[Travis Oliphant] Maybe I have the wrong version of code. In my pyport.h (checked out from svn trunk) I have. #define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)1)) What is size_t? size_t is an unsigned integral type defined by, required by, and used all over the place in standard C. What exactly is the compiler message you get, and exactly which compiler are you using (note that nobody else is having problems with this, so there's something unique in your setup)? Is this supposed to be sizeof(size_t)? No. (size_t)-1 casts -1 to the unsigned integral type size_t, which creates a solid string of 1 bits with the width of the size_t type. 1 then shifts that right one bit, clearing the sign bit but leaving the rest of the integer all 1s. Then that's cast to type Py_ssize_t, which is a signed integral type with the same width as the standard size_t. In the end, you get the largest positive signed integer with the same width as size_t, and that's the intent. I get a syntax error when I actually use PY_SSIZE_T_MAX somewhere in the code. Nobody else does (PY_SSIZE_T_MAX is referenced in a few places already), so you need to give more information. Is it simply that you neglected to include Python.h in some extension module? The definition of size_t must be (according to the C standard) supplied by stdlib.h, and Python.h includes stdlib.h. It's also possible the some core Python C code doesn't #include enough stuff to get the platform's size_t definition. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssize_t branch merged
Tim Peters wrote: [Travis Oliphant] Maybe I have the wrong version of code. In my pyport.h (checked out from svn trunk) I have. #define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)1)) What is size_t? size_t is an unsigned integral type defined by, required by, and used all over the place in standard C. What exactly is the compiler message you get, and exactly which compiler are you using (note that nobody else is having problems with this, so there's something unique in your setup)? I'm very sorry for my silliness. I do see the problem I was having now. Thank you for helping me out. I was assuming that PY_SSIZE_T_MAX could be used in a pre-processor statement like LONG_MAX and INT_MAX. In other words #if PY_SSIZE_T_MAX != INT_MAX This was giving me errors and I tried to understand the #define statement as an arithmetic operation (not a type-casting one). I did know about size_t but thought it strange that 1 was being subtracted from it. I would have written this as (size_t)(-1) to avoid that confusion. I do apologize for my error. Thank you for taking the time to explain it. I still think that PY_SSIZE_T_MAX ought to be usable in a pre-processor statement, but it's a nit. Best, -Travis No. (size_t)-1 casts -1 to the unsigned integral type size_t, That's what I was missing I saw this as subtraction not type-casting. My mistake -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssize_t branch merged
On 2/17/06, Travis E. Oliphant [EMAIL PROTECTED] wrote: I'm very sorry for my silliness. I do see the problem I was having now. Thank you for helping me out. I was assuming that PY_SSIZE_T_MAX could be used in a pre-processor statement like LONG_MAX and INT_MAX. In other words #if PY_SSIZE_T_MAX != INT_MAX I suppose that might be nice, but would require configure magic. I'm not sure how it could be done on Windows. There are much more important problems to address at this point IMO. Just review the recent fixes related to Py_BuildValue() on python-checkins to see what I mean. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ssize_t branch merged
Just in case you haven't noticed, I just merged the ssize_t branch (PEP 353). If you have any corrections to the code to make which you would consider bug fixes, just go ahead. If you are uncertain how specific problems should be resolved, feel free to ask. If you think certain API changes should be made, please discuss them here - they would need to be reflected in the PEP as well. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssize_t branch merged
Great! I'll mark the PEP as accepted. (Which doesn't mean you can't update it if changes are found necessary.) --Guido On 2/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Just in case you haven't noticed, I just merged the ssize_t branch (PEP 353). If you have any corrections to the code to make which you would consider bug fixes, just go ahead. If you are uncertain how specific problems should be resolved, feel free to ask. If you think certain API changes should be made, please discuss them here - they would need to be reflected in the PEP as well. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
