#858 deprecated conversion from string constant to ‘char*’

[Soeren Sonnenburg]

Swig does not make use of const char* foo="bla" in all the python wrapper code (and more?).

As a result one is swamped with

warning: deprecated conversion from string constant to ‘char*’

since gcc-4.2.

[William Fulton]

Logged In: YES
user_id=242951
Originator: NO

We keep fixing more of these. Which version of Python is this for now?

[Olly Betts]

Logged In: YES
user_id=14972
Originator: NO

I've just run into this - the case I see is in some custom typemap code which does:

PyObject * mythis = PyObject_GetAttrString(obj, "this");

In Python 2.4, PyObject_GetAttrString() take char * as its second parameter so we get this warning. In Python 2.5 this has been changed and the second parameter is now const char *. I'd argue that this is a bug in the Python 2.4 (and presumably earlier) API and it's not a productive use of our time to work around warnings with similar causes in SWIG-generated code (there are too many other bug reports languishing in the tracker, and this one will fix itself once Python 2.4 becomes obsolete). Others may feel differently of course.

If SWIG-generated code is directly using char * where it should use const char *, that certainly should be fixed.

[Adam Meier]

Logged In: YES
user_id=1913936
Originator: NO

I have run into this problem as well while attempting to compile a program running cygwin with swig 1.3.31 compiled for i686-pc-cygwin. I also have Python 2.5.1, so unless I am misunderstanding (and I very probably am), my problem does not stem from an outdated version of python. The code is being compiled using a somewhat complicated scons script, but it correctly compiles on my boss's unix machine using the same swig, python, and scons versions. Thanks for any help.

[Olly Betts]

Logged In: YES
user_id=14972
Originator: NO

We need to know where the problem is - just telling us that you are seeing it doesn't help a lot.

If you're easily able to check with the SVN version of SWIG, that would be useful - 1.3.31 is about 11 months old now, and there have been a lot of changes since then.

Failing that, a self-contained .i file which generates wrapper code with the warning would be ideal, but even just the generated C/C++ wrapper code and the compiler output might be enough to work out what is generating the problematic code (and if it's already fixed in SVN).

[Olly Betts]

Logged In: YES
user_id=14972
Originator: NO

I've just committed fixes to SVN for several occurrences of this for PHP and Tcl.

I now get a warning free build for all the swig-generated bindings for Xapian - these are PHP, Tcl, Python, Ruby, and C#. There may be SWIG features this doesn't exercise, but without doing a labourious code audit, I think all we can do is fix reported cases.

[William Fulton]

Logged In: YES
user_id=242951
Originator: NO

These were fixed for the Python test-suite for 1.3.33.