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

Gregory P. Smith added the comment: off the top of my head that might actually work as I _think_ "empty" things are required to consume an unused byte of size no matter what meaning sizeof shouldn't change? Some testing and standards perusing for C99 is in order to confirm that though. ---

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

STINNER Victor added the comment: #ifdef __cplusplus char array[1]; #else char array[]; #endif Does it change the size of the structure between C and C++, sizeof(PyBytesObject)? Also, does the size of the struture matter? :-) I guess that the impart part is the ABI: offset of the mem

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

Antoine Pitrou added the comment: How about: #ifdef __cplusplus char array[1]; #else char array[]; #endif ? -- ___ Python tracker ___ ___

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

Change by Gregory P. Smith : -- versions: +Python 3.11 -Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

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

Antoine Pitrou added the comment: Another possibility yet would be: typedef struct { PyObject_VAR_HEAD Py_hash_t ob_shash; char ob_sval; } PyBytesObject; #define PyBytes_AS_STRING(op) (assert(PyBytes_Check(op)), \ &(((PyBytesObject *)(op))->ob_sval)

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

Gregory P. Smith added the comment: PyBytesObject could become a struct that contains a single opaque internal struct. there is some code out there that references PyBytesObjects internals by field name but my searches across a broad swath of code so far seem to suggest that is so rare this

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

Gregory P. Smith added the comment: agreed, being opaque seems ideal. -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

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

STINNER Victor added the comment: For me, the most sane option is to make structures opaque in the C API, and then flexible array members. I did something similar for atomic types. First, we got tons of build isssues with various C compilers and then with C++ compilers. I moved the header to

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

Gregory P. Smith 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 prob

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

Pablo Galindo Salgado added the comment: > How is it an undefined C behavior? It works well in practice, no? Famous last words ;) -- nosy: +pablogsal ___ Python tracker ___ _

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

Serhiy Storchaka added the comment: AFAIK extern "C" only affects mangling of function names. Because of overloading in C++ you can have several functions with the same name, and to distinguish "int abs(int)" from "float abs(float)" the C++ compiler mangles function names, that makes them in

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

STINNER Victor added the comment: > Undefined C behavior going beyond end of struct via a [1] arrays. How is it an undefined C behavior? It works well in practice, no? -- ___ Python tracker

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

STINNER Victor added the comment: Modules/hashtable.c and Modules/hashtable.h use a different approach. The variable size data is *not* part of the structure: typedef struct { /* used by _Py_hashtable_t.buckets to link entries */ _Py_slist_item_t _Py_slist_item; Py_uhash_t key_ha

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

STINNER Victor added the comment: The following C++ code fails to build: --- #ifdef __cplusplus # include #else # include #endif #ifdef __cplusplus extern "C" { #endif typedef struct { int x; int y; char array[]; } mystruct_t; #ifdef __cplusplus } #endif int main() { siz

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

Gregory P. Smith added the comment: Isn't the only actual way for a C .h file to be compatible with C++ via extern "C" { } which all of our non-meta include files appear to have already? -- ___ Python tracker

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

Serhiy Storchaka added the comment: I concur with Sam that we should keep compatibility with C++ in header files. -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

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

Change by Gregory P. Smith : -- title: Undefined C behavior going beyond end of struct via a char[1]. -> Undefined C behavior going beyond end of struct via a [1] arrays. ___ Python tracker _

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

Change by Gregory P. Smith : -- stage: patch review -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr