classification
Title: Replacing char* with const char*
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.4
process
Status: closed Resolution: fixed
Dependencies: 1699259 9369 Superseder:
Assigned To: serhiy.storchaka Nosy List: amaury.forgeotdarc, belopolsky, brett.cannon, dgreiman, eric.snow, ext-, gustavo, ncoghlan, ned.deily, pitrou, python-dev, serhiy.storchaka, tim.peters
Priority: normal Keywords: patch

Created on 2007-08-12 16:43 by ext-, last changed 2013-10-19 18:40 by python-dev. This issue is now closed.

Files
File name Uploaded Description Edit
const_char.patch ext-, 2007-08-12 16:43 Patch to replace char* with const char* in a few functions
const_char_2.patch serhiy.storchaka, 2013-06-01 13:17 review
const_char_3.patch serhiy.storchaka, 2013-10-14 20:37 review
Messages (15)
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) * (Python committer) 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 <wink>.
"""

"const char*" was accepted without opposition, though.
msg62954 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-02-25 00:25
Douglas Greiman submitted many similar changes with his issue2135 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2013-05-28 19:50
See also issue9369.
msg190445 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-06-01 13:17
The patch is outdated. Some function prototypes were changed in issue9369, 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) * (Python committer) 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) * (Python committer) 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
History
Date User Action Args
2013-10-19 18:40:15python-devsetmessages: + msg200473
2013-10-19 18:23:14ned.deilysetnosy: + ned.deily
messages: + msg200469
2013-10-19 18:05:11serhiy.storchakasetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2013-10-19 18:04:04python-devsetnosy: + python-dev
messages: + msg200458
2013-10-14 21:41:23serhiy.storchakasetnosy: + tim.peters
2013-10-14 20:37:37serhiy.storchakasetfiles: + const_char_3.patch

messages: + msg199948
2013-08-06 13:16:58serhiy.storchakasetassignee: serhiy.storchaka
2013-06-08 15:57:00eli.benderskysetnosy: - eli.bendersky
2013-06-01 13:17:32serhiy.storchakasetfiles: + const_char_2.patch

nosy: + brett.cannon, ncoghlan, eric.snow
messages: + msg190445

stage: needs patch -> patch review
2013-05-28 19:50:25serhiy.storchakasetdependencies: + const char* for PyObject_CallMethod and PyObject_CallFunction
messages: + msg190239
2013-05-14 11:57:11serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg189210
2013-05-13 21:41:43pitrousetmessages: + msg189182
2013-05-13 21:27:58eli.benderskysetmessages: + msg189181
2013-05-13 21:11:53pitrousetversions: + Python 3.4, - Python 2.7
nosy: + pitrou

messages: + msg189178

stage: needs patch
2013-05-13 13:39:18eli.benderskysetnosy: + eli.bendersky
messages: + msg189130
2009-05-15 01:51:24ajaksu2setdependencies: + replacing char* with const char* in sysmodule.c/.h
versions: + Python 2.7, - Python 2.6
2008-02-25 00:25:46belopolskysetnosy: + belopolsky, dgreiman
messages: + msg62954
2008-01-06 12:21:09christian.heimessettype: enhancement
versions: + Python 2.6
2007-12-17 23:52:01amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg58712
2007-12-17 22:28:56gustavosetnosy: + gustavo
messages: + msg58709
2007-08-12 16:43:07ext-create