I got this warning when compiling dbm module with Python 3.4.

/home/sky/Code/python/programming_language/cpython/Modules/_dbmmodule.c: In function ‘newdbmobject’:
/home/sky/Code/python/programming_language/cpython/Modules/_dbmmodule.c:55:5: warning: passing argument 1 of ‘dbm_open’ discards ‘const’ qualifier from pointer target type [enabled by default]
In file included from /home/sky/Code/python/programming_language/cpython/Modules/_dbmmodule.c:16:0:
/usr/include/ndbm.h:55:14: note: expected ‘char *’ but argument is of type ‘const char *’

I have two ndbm.h.

/usr/include/ndbm.h
/usr/include/gdbm/ndbm.h

Both of them expect char *file not const char *file in dbm_open.

I downloaded the newest GNU database manager from http://www.gnu.org.ua/software/gdbm/download.html (gdbm-1.10.tar.gz). It expects char *file as well in dbm_open.

Attached the patch to silent the compiler warning.

But when I searched 'dbm_open' in search engines or did "man dbm_open", I got:

DBM *dbm_open(const char *file, int open_flags, mode_t file_mode);

So I am not really sure about this. Feel free to close this ticket if it is not valid.

I get the same warning on Fedora 19.

However, the signature of dbmopen_impl is generated by argument clinic, so it isn't simply a matter of patching the signature in place. I'm also inclined to consider the *platform* header to be wrong, since the dbm_open API really should be accepting "const char *" rather than "char *".

We should find a way to silence the warning to avoid the false alarm in the build output (a cast to "char *" with a reference to this issue would be the brute force approach), but propagating the incorrect type declaration higher up the call stack is unlikely to be the right approach.

Here is a patch that strncpy() the filename to a char[].

Why wouldn't "dbm_open((char *)file, flags, mode)" work?

Yes, a cast to char* silences the error. But it could potentially brea contract because dbm_open() could alter the content of the string. I'm just paranoid (again). *g*

I suspect dbm_open predates the common availability of "const".  I assert we can safely assume it won't overwrite the contents of the buffer.  (Barring spectacular memory corruption bugs that "const" would be powerless to prevent.)

New changeset 3068ff3d9d1e by Christian Heimes in branch 'default':
Issue #19296: Silence compiler warning in dbm_open.
http://hg.python.org/cpython/rev/3068ff3d9d1e

You are probably right. Let's not get too fancy with compiler warnings.