Did I predict it? Yes and no. I had off-list conversations with @jwakely about it and so I was aware that GCC had issues they were trying to address before they rolled out the same changes. I mentioned that the situation sounded rather awful for them and that I hoped we were avoiding similar problems based on the silence about the change after it landed. But I didn’t know about (or if I knew, I didn’t appreciate) the silent breakage issues. Mea culpa!
Agreed, but that wasn’t really what I was after. I was suggesting that when we announce release candidates, someone run a smoke test against an RC to see if everything explodes or not like it did here. Given how quickly after the release you were able to spot a “stop the world” problem for you, I’m trying to find out if there’s a way we could get that information before we release rather than after as that seems like it will be the least disruptive for all of us.
That may be true, but I don’t know that this part of the discussion is besides the point; to me, it’s the primary point. This unmaintained software is pulling back a conforming change to a compiler, and it’s a change that comes from multiple user requests to please improve the security posture of C and because the C language is evolving into these areas based on the fact that this code isn’t valid. Continuing to not maintain the code is not going to be an option at some point because someday we will switch the default language mode to C23. That’s why I’m super happy to hear @thesamesam (and others) are actively working on trying to get fixes upstreamed; I think that’s going to ultimately be time very well spent. I greatly appreciate those efforts!
Fantastic! Out of curiosity, what are your thoughts on the suggestion from @MaskRay? Does that give you enough breathing room, or does it cause other hardships? (I was thinking this would also help with implicit int issues that @thesamesam said they’ve also hit a few of.)