After deep study of the whole ring strict alias issue, I've come to the conclusion that the -resulting- binary is effectively the same, and my test case was swapping the apr .so files between builds of httpd 2.4.54 / apr 1.7.0 and httpd 2.4.x/ apr 1.7.x. Running httpd test, no errors were introduced, all binaries loaded and ran fine. Someone building Subversion might want to repeat that exercise.
So this was entirely a work-around to ensure the grammar didn't escape notice when types and values were switched around in ways that a compiler might over-optimize. There were instances where -O3 could break apr at one point, and I'm wondering if this might have been that root cause? I think we can accept this very unusual (for a stable release branch) contortion, since code correctly compiled on either 1.7.0 or 1.7.branch appear to accomplish the same and are binary-stable, only using different syntaxes to get there. Any final thoughts before we simply release 1.7 branch as-is? Bill On Wed, Sep 7, 2022 at 11:06 AM Eric Covener <cove...@gmail.com> wrote: > > On Thu, Jul 28, 2022 at 12:59 PM William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > > > Hello friends and collaborators, > > > > I'm still rather certain this change is ABI and API contract-breaking > > on the apr-1.7.x branch, which holds the project hostage for providing > > a well-understood security fix on the legacy branch. Such things > > can't persist, our individual maintenance branches must also observe > > semver, such that anyone could consume a maintenance branch and > > not be API nor ABI broken against the prior sub-version release; > > > > https://github.com/apache/apr/compare/1.7.0...1.7.x#diff-86c28ef8e95257a8d60ce73f3262290e91fc5ca3eb722144a6c99559ddf717cf > > > > I'd propose a radical solution, either all of include/* excluding most > > of private / arch/* have no adverse effects on a rebuild, or we revert > > the whole branch to the last stable release, in 7 days. Allow a 7 day > > window to reintroduce critical and desired changes that don't break > > our dev guidelines; > > > > https://apr.apache.org/versioning.html. > > > > All other questions were resolved at least 4 weeks ago, as can > > be observed from include/* changes which alter the incremental > > consumer's observations, github makes this simple; > > > > https://github.com/apache/apr/compare/1.7.0...1.7.x# > > > > So I think we are nearly ready 14 days from now to tag 1.7.1 > > and solve this conundrum. If it can be proven than the existing > > 1.7.0 or 1.7.1 builds would be entirely compatible and not break > > developer's expectations when deployed against either 1.7.1 > > or 1.7.0 in the next 7 days, my objection is withdrawn and we > > will tag this code in one week, not waiting for 2 weeks. > > > > Who wants to help prove up or down that it should persist and > > work out the back-out as needed? Otherwise I ask the project > > member's permissions to work from a new 1.7.x-rebuild branch > > for the following week based on 1.7.0, and replace 1.7.x with > > the 1.7.x-rebuild branch one week later. > > Should we just back out r1896748 (ring strict aliasing thing) out at > this stage? I think the radical solution is too labor intensive and > unlikely to progress.
