[Python-Dev] Const-correctness in C-API Object Protocol
Guido van Rossum
guido at python.org
Tue Feb 22 20:06:41 CET 2011
On Tue, Feb 22, 2011 at 10:55 AM, Brett Cannon <brett at python.org> wrote:
>
>
> On Mon, Feb 21, 2011 at 15:34, David Claridge <daave at daave.com> wrote:
>>
>> Hi,
>>
>> I was wondering if there is some reason why C API functions like
>> PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments
>> rather than const char*s? If there is some reason these methods will
>> modify their string arguments, it would be nice if it was documented,
>> because at the moment it's unclear whether it is safe to cast a string
>> literal to char* in these cases. For instance it seems reasonable that
>> I should be able to call PySys_GetObject("path") without having to
>> deal with a 'deprecated conversion from string constant to ‘char*’'
>> error.
>
> Probably because (a) the person who first wrote them used char* instead of
> const char*, and (b) it gives us API flexibility by not promising to not
> alter the char array at some point in the future.
I'm sorry, but (b) does not make sense. These APIs typically get
passed string literals and modifying the argument would be a bad idea.
FWIW, in Python 3.2, PySys_GetObject() is actually using const char *.
I don't see a problem with changing PyObject_CallMethod() and its
variations as well.
Though I do not get that warning -- which compiler and version issues
it? Is it a C or a C++ compiler? (If it is a C++ compiler I'm tempted
to reject the complaint -- CPython is not written in C++ even though
at various points we try to keep the headers usable with C++ as well
as with C.)
--
--Guido van Rossum (python.org/~guido)
More information about the Python-Dev
mailing list