Gregory P. Smith <g...@krypto.org> added the comment:
updates: - extern "C" is indeed really only about linking so it has no bearing. What I'm hearing from talking to our C++ compiler team is unfortunately sad: The C++ standard does not support flexible array member syntax on purpose because it leads to problems specific to C++ (ex: what do "new" and "del" do?) So some compilers will reject such code (just as some accept it treating it as C99 does). Meaning we can't do this in any public header file. One workaround would indeed be to do something similar to that hashtable code, but it is quite annoying and I don't know that we could actually change the definition of PyBytesObject that way as its internals could be referenced externally. (though all the bytes should line up regardless so even macros before and after such a change would be compatible?) Within our internal private pure C code we could move to use this feature; things in .h files are the cross language issue. Anyways I'm following up internally to better understand the motivation for wanting code to not use the "it's worked forever" technically undefined behavior of the trailing [1] member and out of bounds access. Pondering, I wonder if this could turn into a "-fwrapv" style of situation, we depend on that behavior working so we adopted the compiler flag when compilers started to care; so at most we might some day need to pass another compiler flag to ensure it stays? we'll see. I'm inclined not to move forward with my PRs for now. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40120> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
