This is a meta-ticket for a number of small PRs that clean up some internals.

Issues will include:

* Removing unnecessary casts
* consting pointers that can be made const
* Removing unused function arguments
* etc

New changeset 982307b9cceef36e30ac43b13032d68c3b921adc by Andy Lester in branch 'master':
bpo-39943: Remove unused self from find_nfc_index() (GH-18973)
https://github.com/python/cpython/commit/982307b9cceef36e30ac43b13032d68c3b921adc

New changeset 62d21c9d900664b2ca30c2d7edd80b6628abdf62 by Andy Lester in branch 'master':
bpo-39943: Properly const the pointers in dictkeys_get_index (GH-19170)
https://github.com/python/cpython/commit/62d21c9d900664b2ca30c2d7edd80b6628abdf62

What is the rationale for adding const? For example, does the PR 19185 fix any compiler warning or any bug? While PR 19185 is correct, I am not sure that we should modify the 607K lines of C code of CPython to add const everywhere. I'm fine with using const for new code, but I'm not sure that it's worth it to modify exiting code.

It doesn't quiet any compiler warnings given the default compiler warnings that ./configure sets.  

However, it does quiet the -Wcast-qual compiler warning that could be a helpful addition some time in the future. I think it would be great, for example, if it were made impossible to send a pointer that points at a string literal into a function that would modify its contents.

Consting pointers also helps static analyzers like splint by letting it know the intent of the API.  It makes it possible for the analyzer to detect uninitialized buffers, for example.

All of the 20 or so patches that I've submitted, like BPO 39770 that you merged, have come about from my cranking up the warning options on both GCC and clang and sifting through the warnings.  My hope is that by making more things const, we can detect existing bugs and prevent new ones.

You say "I'm not sure that it's worth it to modify exiting code."  Is your concern the amount of work it would take to find the problems?  If so, it's not that much work when you let the compiler find the problems, which I've done.  I've already spent the time digging and validating.

> However, it does quiet the -Wcast-qual compiler warning that could be a helpful addition some time in the future.

Aha, that's intesting. It helps me if I can see that your change fix a compiler warning that I can reproduce. If I build Objects/obmalloc.c with -Wcast-qual using GCC 9.2.1 (on Fedora 31), I get:

Objects/obmalloc.c:2455:66: warning: cast discards 'const' qualifier from pointer target type [-Wcast-qual]
 2455 |     fprintf(stderr, "    The %d pad bytes at tail=%p are ", SST, (void *)tail);
      |                                                                  ^


But I get no warning for pymemallocator_eq().


About the (void *) cast, it was added by Zackery Spytz in bpo-36594:

commit 1a2252ed39bc1b71cdaa935d7726d82909af93ab
Author: Zackery Spytz <zspytz@gmail.com>
Date:   Mon May 6 10:56:51 2019 -0600

    bpo-36594: Fix incorrect use of %p in format strings (GH-12769)
    
    In addition, fix some other minor violations of C99.

(...)
-    fprintf(stderr, "    The %d pad bytes at tail=%p are ", SST, tail);
+    fprintf(stderr, "    The %d pad bytes at tail=%p are ", SST, (void *)tail);
(...)

Extract of the issue:

"""
gcc warns with -pedantic:

ptr.c: In function ‘main’:
ptr.c:5:13: warning: format ‘%p’ expects argument of type ‘void *’, but argument 2 has type ‘int *’ [-Wformat=]
     printf ("%p", &i);
"""

We should check that GCC doesn't emit warning with -pedantic nor -Wcast-qual, and when both flags are combined :-)

Casting tail to (void *)tail was the correct thing to do.  The problem is that casting to void* casts away the constness of tail.  The even more correct thing to do is what my patch does, which is cast it to (const void *)tail.

There is no functional difference between sending a const void * and a void * to fprintf.  However, it's one more bit of noise for -Wcast-qual to gripe about.  My hope is to clear up the noise to find the real problems.

For example, if you had this very bad code:

    const char *msg = "literal";
    strcpy(msg, "another string");

then the compiler would complain you're passing a non-const char * to the first arg of strcpy that wants a const char *.  That's a good thing.

However, you could naively change that to:

    strcpy((char *)msg, "another string");

and that would compile just fine, but the code would still be a big problem. It would require -Wcast-qual to warn you that you're casting away the constness of a pointer.

...

For pymemallocator_eq, changing the arguments to const doesn't quiet any warnings in this case with this one function.  However, it's good to make them const because the arguments are not getting modified.  They're getting passed to memcmp(), which properly takes const void *.

New changeset fc2d8d62af25be90f5fd490df141a775d9619b23 by Andy Lester in branch 'master':
bpo-39943: Remove unnecessary casts in import.c that remove constness (GH-19209)
https://github.com/python/cpython/commit/fc2d8d62af25be90f5fd490df141a775d9619b23

New changeset 2c003eff8fef430f1876adf88e466bcfcbd0cc9e by Serhiy Storchaka in branch 'master':
bpo-39943: Clean up marshal.c. (GH-19236)
https://github.com/python/cpython/commit/2c003eff8fef430f1876adf88e466bcfcbd0cc9e

New changeset 38ada3bac8205a7690d573d715b0e84e60297c4c by Andy Lester in branch 'master':
bpo-39943: Keep constness of pointer objects. (19405)
https://github.com/python/cpython/commit/38ada3bac8205a7690d573d715b0e84e60297c4c

New changeset cd8295ff758891f21084a6a5ad3403d35dda38f7 by Serhiy Storchaka in branch 'master':
bpo-39943: Add the const qualifier to pointers on non-mutable PyUnicode data. (GH-19345)
https://github.com/python/cpython/commit/cd8295ff758891f21084a6a5ad3403d35dda38f7

New changeset 8f87eefe7f0576c05c488874eb9601a7a87c7312 by Serhiy Storchaka in branch 'master':
bpo-39943: Add the const qualifier to pointers on non-mutable PyBytes data. (GH-19472)
https://github.com/python/cpython/commit/8f87eefe7f0576c05c488874eb9601a7a87c7312

Not sure if it's related to changes made recently on this issue, but I started to notice these compiler warnings on Windows:



D:\a\cpython\cpython\Modules\sre_lib.h(822,21): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1058,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1064,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1134,13): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(822,21): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1058,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1064,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1134,13): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(822,21): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1058,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1064,17): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\sre_lib.h(1134,13): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\_sre.c(457,26): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]
D:\a\cpython\cpython\Modules\_sre.c(471,26): warning C4090: 'function': different 'const' qualifiers [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]

Yes, it is a consequence of PR 19345. But it looks like a compiler bug. It complains about implicit conversion from `const void **` to `void *` in memcpy() and PyMem_Del().

I remember coming across a similar error from GCC about casting from a const double pointer to a single pointer void and it said (I believe) something about having to have each cast having to be valid.  I think it was implying something like that if you have 

const void **p

you have to cast that as

(void *)(const void *)p

I will see if I can find that message and/or I can find out more about this cast problem in the Windows compiler.

I'm assuming that you're getting this sre_lib.h error when compiling Modules/_sre.c.

> Yes, it is a consequence of PR 19345. But it looks like a compiler bug. It complains about implicit conversion from `const void **` to `void *` in memcpy() and PyMem_Del().

Is it possible to add an explicit cast to make the compiler warnings quiet?

For sre.c, this is definitely a bug in MSVC, see:

* https://stackoverflow.com/questions/10403713/why-does-visual-c-warn-on-implicit-cast-from-const-void-to-void-in-c-but
* https://godbolt.org/z/BpMqA_


I'm trying to get rid of MSVC warnings to unblock https://github.com/python/cpython/pull/18532 so I'll make a pull request that adds explicit casts for this.

New changeset 06e3a27a3c863495390a07c695171a8e62a6e0d2 by Ammar Askar in branch 'master':
bpo-39943: Fix MSVC warnings in sre extension (GH-20508)
https://github.com/python/cpython/commit/06e3a27a3c863495390a07c695171a8e62a6e0d2

If someone is interested, there is a one remaining compiler warning in frameobject.c which is likely easy to fix:

D:\a\cpython\cpython\Objects\frameobject.c(400,1): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]

See https://bugs.python.org/issue40228#msg368383

---

Moreover, the following change introduced a warning in pythonrun.c:

D:\a\cpython\cpython\Python\pythonrun.c(579,21): warning C4244: '=': conversion from 'Py_ssize_t' to 'int', possible loss of data [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]

commit 15bc9ab301d73f20bff47a12ef05326feb40f797
Author: Guido van Rossum <guido@python.org>
Date:   Thu May 14 19:22:48 2020 -0700

    bpo-40612: Fix SyntaxError edge cases in traceback formatting (GH-20072)

New changeset cf8d6ef9629dc1bffadfcec251a2ffe30d5addaa by Miss Islington (bot) in branch '3.9':
bpo-39943: Fix MSVC warnings in sre extension (GH-20508)
https://github.com/python/cpython/commit/cf8d6ef9629dc1bffadfcec251a2ffe30d5addaa