You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Upgrade bundled Expat to 2.8.2 (e.g. for the fix to CVE-2026-56132 and 12 others) #152216
@cdce8p we saw that symptom upstream with clang-based emscripten off Ubuntu 22.04 (3.1.5~dfsg-3ubuntu1) and updating to Ubuntu 24.04 (3.1.6~dfsg-7) made it go away as documented. Upstream CI is using Linux Clang 21 in many places with -Werror and is all green. So my guess is that it's either Apple Clang or the version of it that is the issue here. If you dig into the issue deeper, I'd be curious to learn what you find for the cause.
@cdce8p So my guess is that it's either Apple Clang or the version of it that is the issue here. If you dig into the issue deeper, I'd be curious to learn what you find for the cause.
I definitely saw that with older clang versions, I never determined exactly when this changed; I just ran a test with the latest release of Apple Clang, it it doesn't show the warnings. This was both building libexpat using its own CMake build, and cpython (via autotools) with the embedded expat version.
This is the AppleClang version with which I tested-
% /usr/bin/clang --version
Apple clang version 21.0.0 (clang-2100.1.1.101)
Target: arm64-apple-darwin25.5.0
Ok, it's because cpython's non-debug build turns on -Wunreachable-code - this results in warnings from both AppleClang and clang. It would be possible to disable -Wunreachable-code-fallthrough specifically.
Ok, it's because cpython's non-debug build turns on -Wunreachable-code - this results in warnings from both AppleClang and clang. It would be possible to disable -Wunreachable-code-fallthrough specifically.
Should this be added to xmltok_impl.c upstream then?
@cdce8p I have no interest in adding things like that to the Expat code base.
i tend to agree. Libexpat has its own buildsystem(s), which set appropriate flags for the code; Cpython takes the code, but builds it itself. I would suggest making the change in Cpython's build system for building expat somewhere.
Out of interest, are these warnings showing up in CI ?
I don't think we should be ignoring warnings, we also shouldn't be fixing them, they should be resolved upstream instead. Previously, there were several warnings which this update allowed us to remove from our ignore list.
I would like to note that Expat CI is using -Wall -Wextra -pedantic with -Werror and that -Wunreachable-code-fallthrough is beyond that. The goal of libexpat is to fix bugs, not to address warnings beyond -Wextra that do not expose actual bugs. If there is a bug to fix related to this warning, an in-depth analysis is welcome upstream.
I would like to note that Expat CI is using -Wall -Wextra -pedantic with -Werror and that -Wunreachable-code-fallthrough is beyond that.
To be fair, AFAIK CPython only enables -Wunreachable-code explicitly. While I do share the desire to get these kind of changes upstream, I can also understand the position not to include it. Anyway, I opened #153671 in case silencing it during the build is ok. There at least seems to be some precedent to doing that for other warning types.
Activity
-Wimplicit-fallthroughwarning forModules/expat#125506 as a duplicate of this issuegh-152216: Update bundled expat to 2.8.2 (GH-152234)
[3.14] gh-152216: Update bundled expat to 2.8.2 (GH-152234) (#153525)
[3.15] gh-152216: Update bundled expat to 2.8.2 (GH-152234) (#153524)
cdce8p commentedon Jul 13, 2026
I'm seeing a lot of new compiler warnings with clang on macOS after #152234 was merged. They all are about
-Wunreachable-code-fallthrough, e.g.:All warnings
hartwork commentedon Jul 13, 2026
@cdce8p we saw that symptom upstream with clang-based emscripten off Ubuntu 22.04 (3.1.5~dfsg-3ubuntu1) and updating to Ubuntu 24.04 (3.1.6~dfsg-7) made it go away as documented. Upstream CI is using Linux Clang 21 in many places with
-Werrorand is all green. So my guess is that it's either Apple Clang or the version of it that is the issue here. If you dig into the issue deeper, I'd be curious to learn what you find for the cause.CC @neek78
neek78 commentedon Jul 13, 2026
I definitely saw that with older clang versions, I never determined exactly when this changed; I just ran a test with the latest release of Apple Clang, it it doesn't show the warnings. This was both building libexpat using its own CMake build, and cpython (via autotools) with the embedded expat version.
This is the AppleClang version with which I tested-
neek78 commentedon Jul 13, 2026
Ok, it's because cpython's non-debug build turns on -Wunreachable-code - this results in warnings from both AppleClang and clang. It would be possible to disable -Wunreachable-code-fallthrough specifically.
cdce8p commentedon Jul 13, 2026
Should this be added to
xmltok_impl.cupstream then?hartwork commentedon Jul 13, 2026
@cdce8p I have no interest in adding things like that to the Expat code base.
neek78 commentedon Jul 13, 2026
i tend to agree. Libexpat has its own buildsystem(s), which set appropriate flags for the code; Cpython takes the code, but builds it itself. I would suggest making the change in Cpython's build system for building expat somewhere.
Out of interest, are these warnings showing up in CI ?
cdce8p commentedon Jul 13, 2026
In that case another option might be to add
-Wno-unreachable-code-fallthroughhere:cpython/Makefile.pre.in
Lines 1451 to 1452 in 1fece44
@StanFromIreland Would that be acceptable?
StanFromIreland commentedon Jul 13, 2026
I don't think we should be ignoring warnings, we also shouldn't be fixing them, they should be resolved upstream instead. Previously, there were several warnings which this update allowed us to remove from our ignore list.
hartwork commentedon Jul 13, 2026
I would like to note that Expat CI is using
-Wall -Wextra -pedanticwith-Werrorand that-Wunreachable-code-fallthroughis beyond that. The goal of libexpat is to fix bugs, not to address warnings beyond-Wextrathat do not expose actual bugs. If there is a bug to fix related to this warning, an in-depth analysis is welcome upstream.cdce8p commentedon Jul 13, 2026
To be fair, AFAIK CPython only enables
-Wunreachable-codeexplicitly. While I do share the desire to get these kind of changes upstream, I can also understand the position not to include it. Anyway, I opened #153671 in case silencing it during the build is ok. There at least seems to be some precedent to doing that for other warning types.cpython/Makefile.pre.in
Lines 1518 to 1519 in 701a7c5
[3.13] gh-152216: Update bundled expat to 2.8.2 (GH-152234) (#154747)
[3.12] gh-152216: Update bundled expat to 2.8.2 (GH-152234) (GH-154747)…
[3.11] gh-152216: Update bundled expat to 2.8.2 (GH-152234) (#155576)
[3.10] gh-152216: Update bundled expat to 2.8.2 (GH-152234) (#155577)