[issue40120] Undefined C behavior going beyond end of struct via a char[1].

Gregory P. Smith added the comment: """ The [1] thing is used in more places: PyObject *f_localsplus[1]; in PyFrameObject PyObject *ob_item[1]; in PyTupleObject void *elements[1]; in asdl_seq and int elements[1];` in asdl_int_seq digit ob_digit[1]; in PyLongObject Py_ssize_t ob_array[1];

[issue40120] Undefined C behavior going beyond end of struct via a char[1].

STINNER Victor added the comment: > Currently, C++ code that includes `` is warning-free in GCC (g++) > even with `-Wpedantic`. That won't be true after this change, unless > Py_LIMITED_API is defined. By the way, the current trend is to make more and more structures opaque in the C API. Se

[issue40120] Undefined C behavior going beyond end of struct via a char[1].

Sam Gross added the comment: It may be worth considering C-API extensions written in C++. Flexible array members are not part of the C++ standard, although GCC, Clang, and MSVC support them as an extension. GCC and Clang will issue warnings with `-Wpedantic` and MSVC will issue warnings with

[issue40120] Undefined C behavior going beyond end of struct via a char[1].

Gregory P. Smith added the comment: >From the PR comment thread (as I opened that first): """Well, there was no other choice in ISO C89 than using char ob_sval[1];, no? Is char ob_sval[]; supported by the C compiler supported by CPython? Like Visual Studio, GCC, clang and xlc (AIX)? (I don't

[issue40120] Undefined C behavior going beyond end of struct via a char[1].

Change by Gregory P. Smith : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue40120] Undefined C behavior going beyond end of struct via a char[1].

Change by Gregory P. Smith : -- keywords: +patch pull_requests: +18592 pull_request: https://github.com/python/cpython/pull/19232 ___ Python tracker ___ ___

[issue40120] Undefined C behavior going beyond end of struct via a char[1].

New submission from Gregory P. Smith : The correct C99 way to do this is using a char[]. PyBytesObject and unicode's struct encoding_map both do this. Unclear to me if we should backport this to earlier versions or not (because PyBytesObject may be exposed?) Probably, but I also doubt it is