| msg53019 - (view) |
Author: eXt (ext-) |
Date: 2007-08-12 16:43 |
| Many functions use char* where const char* should be used. I've changed this in a few function prototypes which I use while embedding python due to numerous warnings about deprecated casting from string constants to char*. |
|
|
| msg58709 - (view) |
Author: Gustavo J. A. M. Carneiro (gustavo) * |
Date: 2007-12-17 22:28 |
| I was about to submit the very same patch :-) I missed PyErr_NewException, but you missed the PyMapping_* methods ;) Please look into this matter. GCC 4.2 has arrived and it has a new warning. The code: char* kwlist[] = { "target", "encoding", NULL }; now gives a warning like: "warning: deprecated conversion from string constant to ‘char*’" at least when compiling in C++ mode... This means that people have to declare it as "const char* kwlist", which will then trigger another warning when calling PyArg_ParseTupleAndKeywords with such a variable, because the prototype is: PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject *, const char *, char **, ...); The "char **" should be "const char **". ext-, any chance you could fix that too? |
|
|
| msg58712 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *  |
Date: 2007-12-17 23:52 |
| There was once a rather long discussion about "const" in PyArg_ParseTupleAndKeywords: http://mail.python.org/pipermail/python-dev/2006-February/060689.html If you don't read it to the end, here is the conclusion: """ It sounds like the right answer for Python is to change the signature of PyArg_ParseTupleAndKeywords() back. We'll fix it when C fixes its const rules . """ "const char*" was accepted without opposition, though. |
|
|
| msg62954 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2008-02-25 00:25 |
| Douglas Greiman submitted many similar changes with his patch. His patch also amends documentation, which is missing here. I am adding dgreiman to the nosy list here to avoid duplication of effort. I am -0 on the idea. |
|
|
| msg189130 - (view) |
Author: Eli Bendersky (eli.bendersky) * |
Date: 2013-05-13 13:39 |
| For external APIs visible to user code, this can cause some compatibility problems and users may need to at the very least re-compile this code. So -1 here. For new external APIs, having const wherever appropriate should be considered on a case by case basis. For internal code this is a good idea, but I wouldn't go mass-slashing all the code base now replacing char* by const char*. Presenting some examples where this makes sense in particular would be interesting though. +0 |
|
|
| msg189178 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2013-05-13 21:11 |
| > For external APIs visible to user code, this can cause some > compatibility problems and users may need to at the very least > re-compile this code. Can you explain exactly which compatibility problems this would cause? Actually, the point is precisely to make life easier for third-party code, since "const char *" is more accepting than "char *". |
|
|
| msg189181 - (view) |
Author: Eli Bendersky (eli.bendersky) * |
Date: 2013-05-13 21:27 |
| Antoine, I was referring to the discussion linked earlier (http://mail.python.org/pipermail/python-dev/2006-February/060689.html). Users of the C API needed to recompile their code and also add preprocessor hacks to make things compatible with C and C++, AFAIU. |
|
|
| msg189182 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2013-05-13 21:41 |
| > Antoine, I was referring to the discussion linked earlier > (http://mail.python.org/pipermail/python-dev/2006-February/060689.html). Ok, I've read it through. The problem is specifically with pointers-to-pointers: http://mail.python.org/pipermail/python-dev/2006-February/060849.html And indeed, PyArg_ParseTupleAndKeywords() got its "const char **" argument changed back to "char **". But the other consts have stayed (such as the "const char *" argument to the same PyArg_ParseTupleAndKeywords()). So it looks like the patch, in essence, is legit. (of course, in practice, it probably won't apply cleanly, since it's very old; and perhaps it's incomplete too) |
|
|
| msg189210 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2013-05-14 11:57 |
| In C++ we may overload functions for backward compatibility: PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject *, const char *, const char * const *, ...); PyAPI_FUNC(int) PyArg_VaParseTupleAndKeywords(PyObject *, PyObject *, const char *, const char * const *, va_list va); ... #ifdef __cplusplus inline int PyArg_ParseTupleAndKeywords(PyObject *args, PyObject *keywords, const char *format, char * const *kwlist, ...) { int retval; va_list va; va_start(va, kwlist); retval = PyArg_ParseTupleAndKeywords(args, keywords, format, (const char * const *)kwlist, va_start); va_end(va); return retval; } #endif |
|
|
| msg190239 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2013-05-28 19:50 |
| See also . |
|
|
| msg190445 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2013-06-01 13:17 |
| The patch is outdated. Some function prototypes were changed in , some were changed before. Here is a new patch. It adds const qualifier to following public functions: PyObject_DelAttrString, PyObject_HasAttrString, PyObject_GetAttrString, PyObject_SetAttrString, PyObject_DelItemString, PyMapping_DelItemString, PyMapping_HasKeyString, PyMapping_GetItemString, PyMapping_SetItemString, PyFile_FromFd, PyImport_ExecCodeModule, PyImport_ExecCodeModuleEx, PyImport_ExecCodeModuleWithPathnames, PyImport_ImportFrozenModule, PyLong_FromString, PyOS_strtoul, PyOS_strtol, PyOS_Readline, PyMarshal_ReadObjectFromString, PyParser_ParseFile, PyParser_ParseFileFlags, PyParser_ParseFileFlagsEx, PyTokenizer_FromFile. It also changes prototypes of some internal functions and structures and fixes documentation for PyDict_DelItemString. Some of functions already were documented with const qualifier. |
|
|
| msg199948 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2013-10-14 20:37 |
| The patch synchronized with tip. |
|
|
| msg200458 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2013-10-19 18:04 |
| New changeset 3055e61f1e66 by Serhiy Storchaka in branch 'default': Issue #1772673: The type of `char*` arguments now changed to `const char*`. http://hg.python.org/cpython/rev/3055e61f1e66 |
|
|
| msg200469 - (view) |
Author: Ned Deily (ned.deily) * |
Date: 2013-10-19 18:23 |
| Compile errors on OS X 10.8 with clang: cc -Wno-unused-result -Werror=declaration-after-statement -g -O0 -Wall -Wstrict-prototypes -I. -IInclude -I../../source/Include -DPy_BUILD_CORE -c ../../source/Modules/posixmodule.c -o Modules/posixmodule.o In file included from ../../source/Modules/posixmodule.c:5959: /usr/include/util.h:94:5: error: conflicting types for 'openpty' int openpty(int *, int *, char *, struct termios *, ^ ../../source/Include/pyport.h:676:12: note: previous declaration is here extern int openpty(int *, int *, char *, ^ In file included from ../../source/Modules/posixmodule.c:5959: /usr/include/util.h:97:7: error: conflicting types for 'forkpty' pid_t forkpty(int *, char *, struct termios *, struct winsize *); ^ ../../source/Include/pyport.h:678:14: note: previous declaration is here extern pid_t forkpty(int *, char *, ^ 2 errors generated. make: *** [Modules/posixmodule.o] Error 1 |
|
|
| msg200473 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2013-10-19 18:40 |
| New changeset 8bd69bd6e129 by Serhiy Storchaka in branch 'default': Restore prototypes for the 'openpty' and 'forkpty' on BSDI (broken in issue #1772673). http://hg.python.org/cpython/rev/8bd69bd6e129 |
|
|
| msg227753 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2014-09-28 08:29 |
| New changeset 599a957038fa by Serhiy Storchaka in branch 'default': Removed redundant casts to `char *`. https://hg.python.org/cpython/rev/599a957038fa |
|
|