Почему `co_code_adaptive` в `PyCodeObject` приводится к указателю `uint16_t` в макросе `_PyCode_CODE`? ⇐ Python

[Anonymous]

Я изучал исходный код Python 3.11 и наткнулся на макрос _PyCode_CODE. Я заметил, что в этом макросе член co_code_adaptive PyCodeObject приводится к указателю uint16_t*. Однако co_code_adaptive определяется как массив символов длиной 1.

Код: Выделить всё

/*******************************************/
// code in code.h
/*******************************************/
#define _PyCode_CODE(co) ((const uint16_t *)(co)->co_code_adaptive)

#define _PyCode_DEF(SIZE) {                                                    \
// ...                                                                     \
char co_code_adaptive[(SIZE)];                                             \
}
/* Bytecode object */
struct PyCodeObject _PyCode_DEF(1);

Код: Выделить всё

/*******************************************/
// code in specialize.c
/*******************************************/
void
_PyCode_Quicken(PyCodeObject *code)
{
_Py_QuickenedCount++;
int previous_opcode = -1;
_Py_CODEUNIT *instructions = _PyCode_CODE(code);
for (int i = 0; i < Py_SIZE(code); i++) {
int opcode = _Py_OPCODE(instructions[i]);
// ...
}

Похоже, что такое приведение может привести к рискам доступа к памяти, поскольку char и uint16_t имеют разные размеры типов и требования к выравниванию. Почему разработчики Python решили реализовать это именно так? Как в этом контексте обеспечивается безопасность памяти?
В частности, в файле specize.c внутри функции _PyCode_Quicken этот макрос используется для определения uint16_t * указатель с именем инструкции. Затем код обращается к памяти с помощью оператора []. Как Python гарантирует корректность доступа к памяти?
Будем очень признательны за любую информацию об основных проектных решениях или документации, объясняющей этот подход.

Подробнее здесь: https://stackoverflow.com/questions/791 ... nter-in-py