Originally C API didn't use the const qualifier. Over few last years the
const qualifier was added to C API if that preserved backward
compatibility. For example input "char *" parameters were changed to
"const char *". This makes C API compatible with C++, eliminates C
compiler warnings, and helps to found possible errors.
Now I have started to make changes that are not absolute compatible, and
can need modifying third-party code (but unlikely).
* The const qualifier was added to "char *" fields name and doc of some
structures. They always point to C string literals.
https://bugs.python.org/issue28761
* The const qualifier was added to private global variable
_Py_PackageContext. https://bugs.python.org/issue28748
Now I'm going to add the const qualifier to the result of
PyUnicode_AsUTF8AndSize() and PyUnicode_AsUTF8(). These functions return
a reference to internal cached UTF8 representations of a string. It
should never be modified. https://bugs.python.org/issue28769
Later I'm planning following changes:
* Add the const qualifier to the result of functions that return
references to internal representation of immutable objects, like
PyBytes_AS_STRING() or PyUnicode_DATA(). While CPython internally can
modify the content of immutable objets, this is very dangerous, because
this can invalidates invariants and cached values. Third-party code
shouldn't do this.
* Add the const qualifier to the format field of Py_buffer. It is a
reference to C string literal or to the content of bytes object.
Mutating its content is an error. Only _testbuffer overuses the format
field of internal Py_buffer object for owning a reference to allocated
memory. But this is not leaked outside.
What are you think about this?
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
