diff options
| author | Sam James <sam@gentoo.org> | 2025-02-04 15:46:17 +0000 |
|---|---|---|
| committer | Sam James <sam@gentoo.org> | 2025-02-04 15:46:17 +0000 |
| commit | 5b0d1e373dcd8c4f79735d033d205a6f36698c59 (patch) | |
| tree | 6ac4290fba8b9dfe3fc6a2adc1ca466530a0d21a /dev-python/bpython | |
| parent | 6be16d3ef027555b18acf7a6127260080eabbd11 (diff) | |
| download | gentoo-5b0d1e373dcd8c4f79735d033d205a6f36698c59.tar.gz gentoo-5b0d1e373dcd8c4f79735d033d205a6f36698c59.tar.bz2 gentoo-5b0d1e373dcd8c4f79735d033d205a6f36698c59.zip | |
media-libs/id3lib: fix C23 issues as best we can
The situation here is complicated. With C23, 'bool' is exposed properly
out of the box (as the same type as '_Bool'). But this is problematic
when it comes to C++ where 'bool' was always '_Bool' (or near-enough
guaranteed), and where we have existing C applications that we don't
want to break ABI for.
For C++, id3tag was always using native C++ 'bool', so we don't want to change
that now when looking at C23 compat. This means the ABI issues between
C and C++ remain: typedef bool my_bool.
For C, continue using the old 'int bool' that the project did before
C23. This doesn't solve the pre-existing C/C++ ABI issue here where
C++ always had "good _Bool-as-bool", unfortunately: typedef int my_bool.
Really, we need people to port to taglib ASAP.
Bug: https://bugs.gentoo.org/893644
Bug: https://bugs.gentoo.org/949086
Signed-off-by: Sam James <sam@gentoo.org>
Diffstat (limited to 'dev-python/bpython')
0 files changed, 0 insertions, 0 deletions
