Issue994255
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2004-07-20 03:36 by thiagocorrea, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (13) | |||
---|---|---|---|
msg21702 - (view) | Author: Correa (thiagocorrea) | Date: 2004-07-20 03:36 | |
It will make the compiler complain on each instance about the conditional being constant ( while (0) ) why not use something like this instead? The compiler will be able to optimize out the function call. #if !defined(Py_RETURN_NONE) // New in Python 2.4 inline PyObject* doPy_RETURN_NONE() { Py_INCREF(Py_None); return Py_None; } #define Py_RETURN_NONE return doPy_RETURN_NONE() #endif #if !defined(Py_RETURN_TRUE) // New in Python 2.4 inline PyObject* doPy_RETURN_TRUE() {Py_INCREF(Py_True); return Py_True;} # define Py_RETURN_TRUE return doPy_RETURN_TRUE() #endif #if !defined(Py_RETURN_FALSE) // New in Python 2.4 inline PyObject* doPy_RETURN_FALSE() {Py_INCREF(Py_False); return Py_False;} #define Py_RETURN_FALSE return doPy_RETURN_FALSE() #endif |
|||
msg21703 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2004-07-20 11:27 | |
Logged In: YES user_id=80475 Which compiler and operating system are you using? |
|||
msg21704 - (view) | Author: Correa (thiagocorrea) | Date: 2004-07-20 15:27 | |
Logged In: YES user_id=111587 Visual C++ 7.0, Win32 |
|||
msg21705 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2004-07-21 00:40 | |
Logged In: YES user_id=357491 You can't use inline; that is not supported in C89 but only C99 which we do not support. As for why we can't just make the macro ``{Py_INCREF(Py_None); return Py_None;}``, I don't know. K&R seems to suggest that the syntax is at least legal. |
|||
msg21706 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-07-21 01:26 | |
Logged In: YES user_id=31435 "do {...} while(0)" is the standard C idiom for writing a multi- statement macro; the reason "{...}" doesn't work is explained, e.g., here: http://www.eskimo.com/~scs/C-faq/q10.4.html thiagocorrea, we need more words from you. Python is built every day using MSVC 6.0, and Visual Studio 7.1, with no warnings of any kind. Indeed, "no warnings under MSVC" is a groundrule for the Python project. Exactly how do you compile it? Do you use the Visual Studio project files in the PCBuild subdirectory? Brett is correct that we cannot use "inline" either. |
|||
msg21707 - (view) | Author: Correa (thiagocorrea) | Date: 2004-07-21 02:26 | |
Logged In: YES user_id=111587 I'm not building Python. I use python embedded on my project ( sf.net/projects/wpdev ) for scripting. I often build using Level 4 warning (/W4) setting, usefull for finding bugs. Also, it's built using C++ compiler not C. Well, I don't know much about C standards but I do know a lot about C++, and for C++ inline is just a hint to the compiler, it might very well completely ignore it or ( it usually does ) inline functions that were not marked as "inline". If that's the problem, then drop the "inline"... or have a macro to detect that inline is supported by the compiler. #ifdef __cplusplus #define INLINE inline #else #define INLINE #endif Other checks could be added as well to enable it on C99 compliant compilers. The point here is that the compiler is right complainning about the constant conditional there. I know that a simple {} block doesn't work well, but a function call will, and the call itself will also be optimized out by the compiler. |
|||
msg21708 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-07-21 03:05 | |
Logged In: YES user_id=31435 There are at least 27 macros in core Python that use this standard C idiom, and you're the first person to raise an objection. I recommend closing this as "Won't Fix" -- unless you have a much simpler suggestion than rewriting all these things. More mounds of C preprocessor convolution would harm maintainability and readablity for everyone, and if that's the tradeoff, I'd rather you learn how to set an appropriate warning level when compiling Python sources. BTW, Python uses /W3. As the MS docs say, "[/W4] should be used only to provide 'lint' level warnings and is not recommended as your usual warning level setting". We promise no warnings at /W3, but that's all. |
|||
msg21709 - (view) | Author: Correa (thiagocorrea) | Date: 2004-07-21 16:53 | |
Logged In: YES user_id=111587 Again, I'm not compiling python sources, I'm using the public C API. The tradeoff isn't maintainability at all nor readability, unless you want to imply that there is a python developer who can't understand the concepts of function call/definition ;) The question is how the above solution differ from the one in the current source. And that's the warning level, considering that it's the compiler job to optimize out the function call. There is nothing wrong in using /W4 once in a while, and it's acctually a good idea. I'm only asking to change 3 macros, not 27. Or at very least, don't assume it has never been defined before, do a #ifdef, so I can make my own improved version. Perhaps I'm the first person concerned with a clean public API. |
|||
msg21710 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-07-21 18:37 | |
Logged In: YES user_id=31435 Python is written to the C89 standard, and has to compile under a great many C compilers besides the one you use. There's no way we're going to accept preprocessor tricks that end up turning these macros into actual function calls under compilers that don't support "inline" (which isn't part of C89), so that idea was dead on arrival. If you want to submit a patch to stuff #ifndef around the macro definitions you care about, and supply your own compiler-specific versions of those, that would be fine by me. |
|||
msg21711 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-07-21 18:46 | |
Logged In: YES user_id=31435 One other idea for these: Py_INCREF expands to (at worst) a comma-expression under all Python build types, so e.g., #define Py_RETURN_NONE \ return Py_INCREF(Py_None), Py_None should (untested) work. Comma expressions don't create problems with if/else structures. |
|||
msg21712 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2004-07-21 19:23 | |
Logged In: YES user_id=80475 Nick Bastin encountered this same issue with the SunPro C compiler. The solution was to add a compiler specific pragma to pyport.h. I recommend that you submit a similar patch. Assign it to me and I'll apply it for you. Altering the macro itself is probably the wrong way to go. Python has no shortage of while statements with constant conditions. They are everywhere and IMO are a valid idiom. |
|||
msg21713 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-07-21 19:39 | |
Logged In: YES user_id=31435 Which problem did Nick have? Many of the "do {} while(0)" macros in Python are internal to C files, so aren't visible to people merely using the public API (as opposed to compiling Python itself). The three thiagocorrea complains about are part of the public API. I think it's easy to predict that he won't want to disable the "constant expression" message in pyport.h, because then it would be disabled too in all *his* code that merely includes Python.h in order to use the Python C API. I certainly don't mind switching to a different C89 idiom where one is available. |
|||
msg21714 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-07-22 01:49 | |
Logged In: YES user_id=31435 Rewrote Py_RETURN_{NONE, TRUE, FALSE} to expand to comma expressions: Include/boolobject.h; new revision: 1.8 Include/object.h; new revision: 2.128 |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:05 | admin | set | github: 40601 |
2004-07-20 03:36:51 | thiagocorrea | create |