Re: [Python-Dev] Pep 353: Py_ssize_t advice
Martin v. Löwis [EMAIL PROTECTED] writes: c. anyway you'll get a nasty warning, which for some people will be just as bad as an error Try for yourself. You get the warning only if the redefinition is not identical to the original definition (or an object-like macro is redefined as a function-like macro or vice versa). I'm confident that whether you get the warning otherwise is dependent both on the compiler and the compiler-flags you use. But this question is academic now, I think, since you accepted my suggestion. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ 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] Pep 353: Py_ssize_t advice
Martin v. Löwis wrote: David Abrahams schrieb: (C++ allows restating of typedefs; if C allows it, that should be something like): C also allows this; [...] This is nitpicking, since you agreed the change to the PEP, but are you sure that C allows this? From C99 + TC1 + TC2 (http://www.open-std.org/JTC1/SC22/WG14/www/standards): # 6.2.2 Linkages of identifiers # # 6 The following identifiers have no linkage: an identifier declared #to be anything other than an object or a function; [...] (i.e. typedef identifiers have no linkage) # 6.7 Declarations # # Constraints # 3 If an identifier has no linkage, there shall be no more than one #declaration of the identifier (in a declarator or type specifier) #with the same scope and in the same name space, except for tags as #specified in 6.7.2.3. # 6.7.2.3 Tags # # Constraints # 1 A specific type shall have its content defined at most once. (There is nothing else in 6.7.2.3 that applies to typedefs.) Since 6.7 (3) and 6.7.2.3 (1) are constraints, I read this as saying that a C99 implementation must produce a diagnostic if a typedef is redeclared in the same scope. If the program is run despite the diagnostic, its behaviour is undefined. Several C compilers I've used in the past have needed the idempotence guard on typedefs, in any case. -- David Hopwood [EMAIL PROTECTED] ___ 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] Pep 353: Py_ssize_t advice
Pep 353 advises the use of this incantation: #if PY_VERSION_HEX 0x0205 typedef int Py_ssize_t; #define PY_SSIZE_T_MAX INT_MAX #define PY_SSIZE_T_MIN INT_MIN #endif I just wanted to point out that this advice could lead to library header collisions when multiple 3rd parties decide to follow it. I suggest it be changed to something like: #if PY_VERSION_HEX 0x0205 !defined(PY_SSIZE_T_MIN) typedef int Py_ssize_t; #define PY_SSIZE_T_MAX INT_MAX #define PY_SSIZE_T_MIN INT_MIN #endif (C++ allows restating of typedefs; if C allows it, that should be something like): #if PY_VERSION_HEX 0x0205 typedef int Py_ssize_t; # if !defined(PY_SSIZE_T_MIN) # define PY_SSIZE_T_MAX INT_MAX # define PY_SSIZE_T_MIN INT_MIN # endif #endif You may say that library developers should know better, but I just had an argument with a very bright guy who didn't get it at first. Thanks, and HTH. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ 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] Pep 353: Py_ssize_t advice
David Abrahams schrieb: #if PY_VERSION_HEX 0x0205 typedef int Py_ssize_t; #define PY_SSIZE_T_MAX INT_MAX #define PY_SSIZE_T_MIN INT_MIN #endif I just wanted to point out that this advice could lead to library header collisions when multiple 3rd parties decide to follow it. I suggest it be changed to something like: #if PY_VERSION_HEX 0x0205 !defined(PY_SSIZE_T_MIN) Strictly speaking, this shouldn't be necessary. C allows redefinition of an object-like macro if the replacement list is identical (for some definition of identical which applies if the fragment is copied literally from the PEP). So I assume you had non-identical replacement list? Can you share what alternative definition you were using? In any case, I still think this is good practice, so I added it to the PEP. (C++ allows restating of typedefs; if C allows it, that should be something like): C also allows this; yet, our advise would be that these three names get always defined together - if that is followed, having a single guard macro should suffice. PY_SSIZE_T_MIN, as you propose, should be sufficient. 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] Pep 353: Py_ssize_t advice
Martin v. Löwis [EMAIL PROTECTED] writes: David Abrahams schrieb: #if PY_VERSION_HEX 0x0205 typedef int Py_ssize_t; #define PY_SSIZE_T_MAX INT_MAX #define PY_SSIZE_T_MIN INT_MIN #endif I just wanted to point out that this advice could lead to library header collisions when multiple 3rd parties decide to follow it. I suggest it be changed to something like: #if PY_VERSION_HEX 0x0205 !defined(PY_SSIZE_T_MIN) Strictly speaking, this shouldn't be necessary. C allows redefinition of an object-like macro if the replacement list is identical (for some definition of identical which applies if the fragment is copied literally from the PEP). So I assume you had non-identical replacement list? No: a. I didn't actually experience a collision; I only anticipated it b. We were using C++, which IIRC does not allow such redefinition c. anyway you'll get a nasty warning, which for some people will be just as bad as an error Can you share what alternative definition you were using? In any case, I still think this is good practice, so I added it to the PEP. Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ 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] Pep 353: Py_ssize_t advice
David Abrahams schrieb: b. We were using C++, which IIRC does not allow such redefinition You remember incorrectly. 16.3/2 (cpp.replace) says # An identifier currently defined as a macro without use of lparen (an # object-like macro) may be redefined by another #define preprocessing # directive provided that the second definition is an object-like macro # definition and the two replacement lists are identical, otherwise the # program is ill-formed. c. anyway you'll get a nasty warning, which for some people will be just as bad as an error Try for yourself. You get the warning only if the redefinition is not identical to the original definition (or an object-like macro is redefined as a function-like macro or vice versa). 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
